The new primary implementation of Sass is Dart Sass (https://sass-lang.com/dart-sass). New features are implemented there first.
Also, being done in pure javascript, it works way better than node sass for cross-platform compability. For example, in our Jenkins server, node-sass sometimes crashed our server or wasn't working properly with new nodejs versions because of the c++ bindings.
Better yet, there could be the option between the 2 in the config and node-sass / dart-sass could be peer dependencies.
After doing some tests, the Dart implementation seems to be around 25% slower to compile. But it would be nice to remove that bulky node-sass requirement. Hmm.. I'd rather not force every user to manually install one or the other. The huge majority of people won't know or care about the difference.
So the question is: do we want faster compile times (node-sass
), or faster and more reliable npm install
s (dart-sass
)?
In my opinion, I would prefer to have the official and most up-to-date implementation with lightweight npm install even if it's a little slower to compile. And it "just works", no need to install python or other external tools to compile it.
+1 for better cross-platform compatibility by removing compiling dependencies.
node-sass is a pain. If it removes the need to npm rebuild node-sass
, please do it.
+1 for dart-sass
. I can live with 25% slower compiling, when "it just works", which node-sass
doesn't.
+1 for dart-sass
, the compiling might get faster anyway. Reliability all the way
+1 for faster re/install step with dart-sass
.
I agree with others, dart-sass sounds like a way to go (if it really is more reliable than node-sass). Also, it probably takes one issue with node-sass (which tends to be problematic according to community issues) to nullify total saved time in compilation speed.
How easy is for you to replace node-sass with dart-sass? Is there a possibility of breaking changes for Mix users?
For what it's worth Node extensions was made stable in Node 10 and back ported to some later versions of Node 8. This decouples native bindings (like node-sass
/lib-sass
) from the Node version/runtime which removes some of the instability that had been previously felt with node-sass
installs in the past.
I think eventually moving to the sass
dependency on NPM would be a +1 from me if that's what continuously gets support.
It should be noted that:
When installed via npm, Dart Sass supports a JavaScript API that aims to be compatible with Node Sass. Full compatibility is a work in progress, but Dart Sass currently supports the render() and renderSync() functions. Note however that by default, renderSync() is more than twice as fast as render(), due to the overhead of asynchronous callbacks.
I think it should wait until full compatibility has been confirmed and stabilized.
I'm also a bit 馃 with "overhead of asynchronous callbacks" which sounds like it could be extra overhead of async callbacks in the transpiled dart -> JS.
Thanks, everybody.
I'm going to switch to the Dart Sass implementation as a default. Since this will be part of the next major Mix release, I feel okay doing so.
If you want to switch back to node-sass, you can do:
// npm install node-sass
mix.sass('src/app.scss', 'dest', { implementation: require('node-sass') });
Thanks Jeff, though it appears the built stylesheets turn out empty when switching back to node-sass. Using dart-sass produces some weird errors:
ERROR in ./resources/sass/app.scss (./node_modules/css-loader
??ref--5-2!./node_modules/postcss-loader/src
??postcss!./node_modules/resolve-url-loader
??ref--5-4!./node_modules/sass-loader/lib/loader.js
??ref--5-5!./resources/sass/app.scss)
Module build failed (from ./node_modules/sass-loader/lib/loader.js):
display: inline-block
^
Expected newline.
display: inline-block
^
This is on a site where I've upgraded from Mix 2 to 4.
Any ideas?
I think this actually might be related to the fact that I have SCSS stylesheets importing SASS stylesheets, which can't be avoided in any of our projects. Perhaps this is a dart-sass limitation?
Same here. I just upgraded from mix 2.1.14 to mix 4.0.14.
Any ideas how to deal with that:
Expected newline.
Please consider using something like https://www.npmjs.com/package/sass2scss to convert all your sass stuff to scss _for good_, and be done with that.
This is what we did anyway, and no issues since then.
If for some arcane reason you must keep sass indented syntax files, you may also integrate it into your build pipeline. No guarantees it will be any faster though.
There is a new import(ant) point to add to this discussion, as pointed out by rasnauf, which may yield additional performance for dart-sass
while doing dev with hot-reload / incremental builds:
node-sass may be faster than dart-sass, but as of writing this dart-sass is the only library which implements the @use rule, which is strongly recommended over @import. According to the official sass-lang website:
Most helpful comment
Thanks, everybody.
I'm going to switch to the Dart Sass implementation as a default. Since this will be part of the next major Mix release, I feel okay doing so.
If you want to switch back to node-sass, you can do: