Sass Compilation Engines and Parsers in Modern Frontend Stacks
sass and node-sass are compilers that turn SCSS into CSS, while postcss-scss and scss are parsers used for tooling like linting. dart-sass is the legacy name for the current sass package. node-sass is deprecated and should be avoided. Choosing the right tool depends on whether you need full compilation features or just syntax parsing for plugins.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Sass Tooling: Compilers, Parsers, and Legacy Packages
The ecosystem around SCSS includes compilers that generate CSS and parsers that read syntax for tools. sass and node-sass are compilers, while postcss-scss and scss are parsers. dart-sass is the former name of the sass package. Understanding these roles prevents build errors and ensures long-term maintenance.
🛠️ Compilation Engines: Dart vs LibSass
sass is the official compiler. It runs on Dart but compiles to JavaScript for Node.js. It supports all modern Sass features.
// sass: Official compiler
const sass = require('sass');
const result = sass.compileString('$primary: blue; .btn { color: $primary; }');
console.log(result.css);
node-sass binds to LibSass (C++). It is faster in some old benchmarks but lacks new features and is deprecated.
// node-sass: Deprecated compiler
const sass = require('node-sass');
sass.render({ data: '$primary: blue; .btn { color: $primary; }' }, (err, result) => {
console.log(result.css.toString());
});
dart-sass is the legacy package name. It points to the same tool as sass but is no longer updated under this name.
// dart-sass: Legacy package name
const sass = require('dart-sass'); // Works but deprecated
const result = sass.compileString('$primary: blue; .btn { color: $primary; }');
🔍 Syntax Parsers: PostCSS vs Standalone
postcss-scss allows PostCSS to read SCSS syntax. It does not compile variables to CSS by itself. It is used for linting or specific PostCSS plugins.
// postcss-scss: Parser for PostCSS
const postcss = require('postcss');
const scss = require('postcss-scss');
const root = postcss.parse('$var: 1px;', { syntax: scss });
scss is a standalone parser package. It converts SCSS text into an Abstract Syntax Tree (AST) but does not output CSS.
// scss: Standalone parser
const scss = require('scss');
const ast = scss.parse('$var: 1px; .class { color: red; }');
⚠️ Deprecation and Maintenance Status
node-sass is officially deprecated. LibSass is no longer maintained. Using it blocks access to new Sass features like @use and @forward.
// node-sass: Will not support new features
// @use 'sass:color'; // This fails in node-sass
sass is actively maintained. It supports the latest module system and functions.
// sass: Supports modern modules
// @use 'sass:color'; // This works in sass
dart-sass package is deprecated in favor of sass. Installing it may warn you to switch.
// dart-sass: Package deprecated
// npm install dart-sass // Shows deprecation warning
📊 Summary Table
| Package | Type | Status | Use Case |
|---|---|---|---|
sass | Compiler | ✅ Active | Standard CSS compilation |
node-sass | Compiler | ❌ Deprecated | Legacy projects only |
dart-sass | Compiler | ⚠️ Legacy | Old tutorials (use sass) |
postcss-scss | Parser | ✅ Active | PostCSS pipelines |
scss | Parser | ⚠️ Niche | Custom tooling / AST |
💡 Final Recommendation
For compiling styles, always choose sass. It is the standard and stays up to date. Avoid node-sass and dart-sass packages to prevent future breakage. Use postcss-scss only if you need PostCSS to process SCSS files without full compilation.
How to Choose: dart-sass vs node-sass vs postcss-scss vs sass vs scss
- dart-sass:
Do not install
dart-sass. This is the old package name forsass. Using it may trigger deprecation warnings. Switch to thesasspackage instead. - node-sass:
Do not choose
node-sass. It is deprecated, relies on outdated native bindings, and lacks support for new Sass features. Migrate existing projects tosass. - postcss-scss:
Choose
postcss-scssif you need PostCSS plugins to read SCSS syntax without compiling it to CSS. It is ideal for linting or specific transformations within a PostCSS pipeline. - sass:
Choose
sassfor all new projects. It is the official Dart Sass implementation, actively maintained, and supports the latest features like modules and modern functions. - scss:
Avoid
scssfor compilation. It is a parser package that generates an AST, not a full compiler. Use it only for custom tooling that requires syntax analysis.
Popular Comparisons
README for dart-sass
A pure JavaScript implementation of Sass. Sass makes CSS fun again.
|
|
|
This package is a distribution of Dart Sass, compiled to pure JavaScript
with no native code or external dependencies. It provides a command-line sass
executable and a Node.js API.
Usage
You can install Sass globally using npm install -g sass which will provide
access to the sass executable. You can also add it to your project using
npm install --save-dev sass. This provides the executable as well as a
library:
var sass = require('sass');
sass.render({file: scss_filename}, function(err, result) { /* ... */ });
// OR
var result = sass.renderSync({file: scss_filename});
See below for details on Dart Sass's JavaScript API.
API
When installed via npm, Dart Sass supports a JavaScript API that's fully
compatible with Node Sass (with a few exceptions listed below), with support
for both the render() and renderSync() functions. See the Sass
website for full API documentation!
Note however that by default, renderSync() is more than twice as fast as
render() due to the overhead of asynchronous callbacks. To avoid this
performance hit, render() can use the fibers package to call
asynchronous importers from the synchronous code path. To enable this, pass the
Fiber class to the fiber option:
var sass = require("sass");
var Fiber = require("fibers");
sass.render({
file: "input.scss",
importer: function(url, prev, done) {
// ...
},
fiber: Fiber
}, function(err, result) {
// ...
});
Both render() and renderSync() support the following options:
datafilefunctionsimporterincludePathsindentTypeindentWidthindentedSyntaxlinefeedomitSourceMapUrloutFilesourceMapContentssourceMapEmbedsourceMapRootsourceMap- Only the
"expanded"and"compressed"values ofoutputStyleare supported.
No support is intended for the following options:
-
precision. Dart Sass defaults to a sufficiently high precision for all existing browsers, and making this customizable would make the code substantially less efficient. -
sourceComments. Source maps are the recommended way of locating the origin of generated selectors.
See Also
-
Dart Sass, from which this package is compiled, can be used either as a stand-alone executable or as a Dart library. Running Dart Sass on the Dart VM is substantially faster than running the pure JavaScript version, so this may be appropriate for performance-sensitive applications. The Dart API is also (currently) more user-friendly than the JavaScript API. See the Dart Sass README for details on how to use it.
-
Node Sass, which is a wrapper around LibSass, the C++ implementation of Sass. Node Sass supports the same API as this package and is also faster (although it's usually a little slower than Dart Sass). However, it requires a native library which may be difficult to install, and it's generally slower to add features and fix bugs.
Behavioral Differences from Ruby Sass
There are a few intentional behavioral differences between Dart Sass and Ruby Sass. These are generally places where Ruby Sass has an undesired behavior, and it's substantially easier to implement the correct behavior than it would be to implement compatible behavior. These should all have tracking bugs against Ruby Sass to update the reference behavior.
-
@extendonly accepts simple selectors, as does the second argument ofselector-extend(). See issue 1599. -
Subject selectors are not supported. See issue 1126.
-
Pseudo selector arguments are parsed as
<declaration-value>s rather than having a more limited custom parsing. See issue 2120. -
The numeric precision is set to 10. See issue 1122.
-
The indented syntax parser is more flexible: it doesn't require consistent indentation across the whole document. See issue 2176.
-
Colors do not support channel-by-channel arithmetic. See issue 2144.
-
Unitless numbers aren't
==to unit numbers with the same value. In addition, map keys follow the same logic as==-equality. See issue 1496. -
rgba()andhsla()alpha values with percentage units are interpreted as percentages. Other units are forbidden. See issue 1525. -
Too many variable arguments passed to a function is an error. See issue 1408.
-
Allow
@extendto reach outside a media query if there's an identical@extenddefined outside that query. This isn't tracked explicitly, because it'll be irrelevant when issue 1050 is fixed. -
Some selector pseudos containing placeholder selectors will be compiled where they wouldn't be in Ruby Sass. This better matches the semantics of the selectors in question, and is more efficient. See issue 2228.
-
The old-style
:property valuesyntax is not supported in the indented syntax. See issue 2245. -
The reference combinator is not supported. See issue 303.
-
Universal selector unification is symmetrical. See issue 2247.
-
@extenddoesn't produce an error if it matches but fails to unify. See issue 2250. -
Dart Sass currently only supports UTF-8 documents. We'd like to support more, but Dart currently doesn't support them. See dart-lang/sdk#11744, for example.
Disclaimer: this is not an official Google product.