Integrating with PostCSS and modern CSS pipelines

Next: where Sass sits in a modern build pipeline. And what PostCSS does after (or instead of) compilation. Most professional setups compile SCSS first, then run PostCSS plugins on the CSS output.

Typical pipeline order

Sass handles variables, nesting, mixins, and partials. PostCSS handles autoprefixing, future-syntax transforms, minification, and custom property fallbacks. The order matters:

• SCSS to CSS (Dart Sass, sass npm package)
• PostCSS on the compiled CSS
• Output to dist/ or your asset folder

// Input: scss/main.scss
@use 'tokens';
@use 'components/button';

// Sass expands nesting, variables, mixins to plain CSS
// PostCSS then adds prefixes, minifies, etc.

PostCSS config example

/* postcss.config.js - runs on compiled CSS */
module.exports = {
  plugins: [
    require('autoprefixer'),
    require('cssnano')({ preset: 'default' }),
  ],
};

autoprefixer reads your Browserslist config and adds vendor prefixes where still needed. cssnano minifies. Both operate on CSS – they do not understand SCSS syntax.

npm scripts wiring it together

// package.json scripts
{
  "scripts": {
    "scss": "sass scss/main.scss:tmp/main.css --style=expanded",
    "postcss": "postcss tmp/main.css -o dist/main.css",
    "build:css": "npm run scss && npm run postcss",
    "watch": "sass scss/main.scss:tmp/main.css --watch"
  }
}

For watch mode, tools like npm-run-all, chokidar-cli, or bundlers (Vite, webpack) chain Sass and PostCSS automatically. Pick the smallest setup that fits the project – a brochure site does not need webpack for three SCSS files.

What to keep in Sass vs PostCSS

• Sass: token maps, mixins, partial organisation, compile-time brand themes
• PostCSS: autoprefixer, minification, @import inlining of plain CSS, some future-syntax via plugins
• Either, not both: nesting (pick native CSS nesting or Sass nesting – do not double-nest)

Do not use PostCSS to replicate Sass variables on the same project unless you are migrating away from Sass. Two sources of truth for tokens is worse than one.

Source maps through the chain

Enable source maps at the Sass step so DevTools points at SCSS, not compiled CSS:

sass scss/main.scss dist/main.css --source-map

// postcss.config.js - preserve maps
module.exports = {
  plugins: [
    require('autoprefixer'),
  ],
  map: { inline: false },
};

Some PostCSS plugins rewrite maps; test in DevTools after a pipeline change. If line numbers drift, fix the config before debugging styles becomes painful.

PostCSS-only projects

Teams dropping Sass sometimes use PostCSS with postcss-nesting, postcss-custom-properties, and plain CSS modules. That is a valid path – covered in the migration tutorial. For now, treat PostCSS as the polish layer on Sass output, not a rival preprocessor running in parallel.

Try it

• Add autoprefixer and cssnano to a project that already compiles SCSS.
• Chain compile and PostCSS in one npm script; confirm prefixes appear in output.
• Open DevTools and verify source maps still point at your .scss files.