Dart-sass

[john681611]

It's being discussed in sass-loader wondering if it's been considered here as ruby-sass is being deprecated soon.
webpack-contrib/sass-loader#435

[yibn2008]

I think node-sass is fast enough and dart-sass is still under heavily development, so the answer is NO.

[stephanemagnenat]

One reason to allow dart-sass could be that it is supposedly properly supports CSS media query Level 4 syntax, which currently libsass does not. But I agree that the best would be to implement the feature in libsass.

[ngryman]

@yibn2008 Could you reconsider this decision?

We're using dart-sass (aka sass) in production without any issue. I don't think fast-sass-loader needs to be opinionated about the underlying implementation of the SASS compiler as long as the compiler exposes a render function with the appropriate API. Both node-sass and sass are API-compatible.

One suggestion would be to let the consumer specify which compiler he wants to use:

{
  loader: 'fast-sass-loader',
  options: {
    sass: require('sass'),
    sassOptions: require('fibers'),
  },
},

Here is my fork that implements this proposition: ngryman@c876f42. We use it in production without any issue. Note that this fork defaults to use sass because it's made for us, but you could definitely change this behavior and default to node-sass instead.

[ArcanisCz]

I second dart-sass option. Our main issue with node-sass is the binary nature of its dependencies, which are not practical in our enviroments.

[ngryman]

@yibn2008 Any second though about this?

dart-sass is pretty stable now and is a perfectly valid replacement for node-sass in late 2019.

node-sass is native and brings operational limitations compared to a full JavaScript solution:

• It needs a whole toolchain to compile, which in our case, clutters our Docker images.
• It results in slower install times because of the build step.
• It limits dependencies portability and make it more difficult to cache dependencies across several platforms (we need to recompile node-sass specifically).
• It's tied to the Node ABI which is another portable limitation with the latests change of N-API.

Because of those reasons it would make sense for fast-sass-loader to be lose coupled to the underlying implementation. Supporting both implementations would involve minimal changes (cf. ngryman@c876f42) and if you choose to point to node-sass by default, it won't be a breaking change for the current users of your loader.

[johncrim]

In addition, dart-sass is currently the only sass implementation including the new module system, which is a huge advance in sass. The sass project also states that dart-sass is the recommended and go-forward implementation. Right now one can use sass modules (@use) in Angular 9 apps using the regular sass-loader.

[yibn2008]

@ngryman I don't have any experience with dart-sass, but if you really want this feature support, please provider a PR.

[ngryman]

@yibn2008 Awesome, thanks for reconsidering! I'll open a PR based on my fork early January.

[ngryman]

^ For those interested I just opened a PR for that.

[tay1orjones]

LibSass is now officially deprecated

[chrisgbaker]

Has there been any discussion of using sass/embedded-host-node over sass directly, given the poor performance of dart-sass as an npm package?

[yibn2008]

already supported dart-sass