# postcss-scss parses SCSS so PostCSS plugins can read it

> postcss-scss is a PostCSS syntax that reads SCSS source, treating mixins as custom at-rules and variables as properties, so tools like Stylelint can lint and autofix SCSS. It does not compile Sass, and it is the right choice when the goal is to run a PostCSS plugin over SCSS rather than to build stylesheets.

**postcss/postcss-scss** — SCSS parser for PostCSS.

- Repository: https://github.com/postcss/postcss-scss
- Stars: 673 · Forks: 32
- Language: JavaScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/postcss-postcss-scss

## A parser, not a compiler, and the distinction is the whole design

The readme states the contract in one sentence. This module does not compile SCSS. It simply parses mixins as custom at-rules and variables as properties, so that PostCSS plugins can then transform SCSS source code alongside CSS. That two line description tells you everything about where this package sits. Sass is a compiler with its own language features, its own module system and its own output. postcss-scss is a syntax implementation inside PostCSS, and its whole job is to take a file that looks like SCSS and produce a PostCSS AST that PostCSS plugins understand. The specific trick is worth spelling out because it is the design decision. A Sass variable is not a property and a Sass mixin is not an at-rule, but PostCSS only knows about properties, at-rules and selectors, so the parser maps them onto the nearest equivalents. That mapping is what allows a plugin written for CSS to walk over an SCSS file without choking on the Sass-specific syntax. The package name in the manifest is postcss-scss, the version is 4.0.9, and the author is Andrey Sitnik, who is also the author of PostCSS itself, so this sits in the same family of tools rather than being a third party reimplementation.

## Two documented uses, and the second one surprises people

The readme splits the usage into two cases, and the first is the obvious one. The main use case of this plugin is to apply PostCSS transformations directly to SCSS source code, and the example given is linting SCSS source with Stylelint, where the linter will automatically fix issues in the source. The configuration is a syntax setting rather than a plugin:

```js
// postcss.config.js
module.exports = {
  syntax: 'postcss-scss',
  plugins: {
    …
  }
}
```

The second use case has nothing to do with Sass. You can use this parser just to add single line comments to your PostCSS project, without any Sass at all. The example shows a custom property with a double slash comment above it:

```scss
:root {
    // Main theme color
    --color: red;
}
```

The readme also spells out that you do not need a special stringifier to handle the output, since the default one will automatically convert single line comments into block comments. That detail matters for anyone who has tried this and been surprised that their comments come back as slash star blocks. If you want the Sass behaviour of removing inline comments entirely, the readme points at the postcss-strip-inline-comments plugin as the way to do that. So the parser is separable from the Sass handling, and you can take the comment parsing without the rest.

## Installing it is one npm command with an unusual flag order

Installation is a single line, and the readme writes it in a way worth copying exactly rather than from memory:

```bash
npm --save install postcss postcss-scss
```

The flags come before the install verb rather than after it, which is the older npm invocation style and still works. The important part is that postcss itself is installed alongside, because postcss-scss is not a standalone tool. The manifest makes that explicit with a peerDependencies entry requiring postcss ^8.4.29, so a project on an older PostCSS major version cannot use this package without upgrading. The engines field asks for Node 12.0 or newer, which is a low floor and says something about the code being plain JavaScript with no build step of its own. The package also declares a set of funding entries for OpenCollective, Tidelift and GitHub Sponsors, and the readme carries a sponsored-by badge for Evil Martians, so the project has the same sponsorship infrastructure as the wider PostCSS family. For a security report, the readme directs you to the Tidelift security contact, which coordinates the fix and disclosure.

## The export map shows the parser is usable on its own

The exports field in the manifest is longer than a small utility package usually needs, and it tells you the module is more than a single parser function. The default export points at the syntax entry with separate require and import builds, a CommonJS file and an ES module file, plus TypeScript declarations. Then there are individual subpath exports for nested-declaration, scss-parse, scss-parser, scss-stringifier, scss-stringify and scss-tokenize. That list is a compact description of the internal pipeline. Tokenize produces the token stream, parse turns tokens into an AST, stringify turns the AST back into a string, and nested-declaration is the piece that handles Sass style nesting where a declaration appears inside another rule. The scss-parser and scss-stringifier entries are the pieces a plugin author would use when they want SCSS behaviour but not the full syntax override. The main field points at the scss-syntax module, which is the drop-in for the syntax option in a PostCSS config. The types entry points at a declaration file, so a TypeScript project gets typing on the entry points without needing the internal ones.

## Testing is split into unit, lint and integration runs

The scripts section of the manifest shows how the project checks itself, and it is a three part setup rather than a single test command. The unit tests run with uvu, the test script for lint runs eslint over the project, and the integration test runs a node script in the test directory. The aggregate test command sets FORCE_COLOR=1 and then runs every script whose name starts with test:, which is a pattern match on the script names. The repository layout supports that split. The top level has a test/ directory, a lib/ directory holding the implementation, a CHANGELOG.md, a LICENSE, and a pnpm-lock.yaml, so the package manager in use is pnpm even though the install example uses npm. There is a .npmignore and an .editorconfig alongside the .gitignore, and the .github directory holds the workflow configuration. The consequence for a consumer is that the package ships no compiled artefacts to build, since the main field points at a .js file and the type definitions sit next to it, so installing it adds very little to a build pipeline compared with a package that needs transpilation.

## Where this parser is the wrong choice

The main limitation is the one the readme leads with, and it is worth being blunt about it. If you need Sass features, this package does not provide them. There is no variable evaluation, no mixin expansion, no import resolution, no nesting flattening and no colour function library. A file that uses Sass features will be parsed and passed to plugins as a tree that still contains the Sass constructs, which is exactly what you want for linting and exactly what you do not want for producing CSS. The second limitation is that parsing is not the same as understanding. Because variables are treated as properties and mixins as at-rules, a plugin that inspects values may see a Sass expression where it expected a computed value, and any tool that tries to reason about the final cascade will be reasoning about a partially unresolved stylesheet. The alternative approaches differ in kind. Sass itself is the compiler, and using it means Sass handles the language while PostCSS handles the CSS afterwards, which is the arrangement most projects end up with. Preprocessors other than Sass, and CSS nesting as a native feature, take the problem away entirely if your source does not need Sass specific syntax. The genuinely distinct use case for this package is running PostCSS plugins, and particularly a linter with autofix, over source that is written in SCSS but not yet compiled.

## Conclusion

postcss-scss is worth adding when you already run PostCSS and want the same plugin chain applied to SCSS, particularly to get Stylelint's autofix working on Sass files, and its parser plus stringifier pair is small enough to be a low-risk dependency. It is the wrong tool if you need Sass itself, since it compiles nothing, and it is the wrong tool if your only goal is to have double slash comments in plain CSS, where the built-in comment handling may already be enough. Verify first that your PostCSS version satisfies the peer dependency of postcss ^8.4.29, that your Stylelint version can accept a custom syntax, and that the inline comment output you get matches what your build pipeline expects. The last push was on 2026-08-11 and the repository publishes no GitHub releases.

## FAQ

### Does postcss-scss compile SCSS to CSS?

No. The readme says plainly that the module does not compile SCSS. It parses mixins as custom at-rules and variables as properties so that PostCSS plugins can transform SCSS source code alongside CSS.

### How do I configure postcss-scss for Stylelint?

Set the syntax in your PostCSS config to postcss-scss. The readme notes that you can then lint SCSS source with Stylelint and the linter will automatically fix issues in the source.

### Can I use postcss-scss just to support inline comments without Sass?

Yes. The readme describes using the parser to add single line comments to a PostCSS project without any Sass, and says the default stringifier will convert those single line comments into block comments automatically.

### What PostCSS version does postcss-scss require?

The manifest declares a peer dependency on postcss ^8.4.29, and the engines field asks for Node 12.0 or newer. The package ships plain JavaScript with type declarations and no build step of its own.

### How do I remove inline comments like Sass does?

The readme points at the postcss-strip-inline-comments plugin for that behaviour, since the default stringifier converts single line comments into block comments rather than removing them.

## Sources

- [Issues](https://github.com/postcss/postcss-scss/issues)
- [License: MIT](https://github.com/postcss/postcss-scss/blob/main/LICENSE)
- [postcss/postcss-scss on GitHub](https://github.com/postcss/postcss-scss)
- [README](https://github.com/postcss/postcss-scss/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/postcss-postcss-scss