Allow dart-sass DartVM executable rather than pure-js.

[jrood]

🚀 Feature request

Command (mark with an x)

- [x] build
- [x] serve

Description

Angular currently uses the slow compiled-to-pure-js implementation of dart-sass.

The pure JS version is slower than the stand-alone executable (https://sass-lang.com/dart-sass)

Describe the solution you'd like

There should be an option (in angular.json) to use the fast DartVM executable for dart-sass.

[clydin]

Are you experiencing performance issues? The fibers package is automatically used if present within the project which can dramatically improve performance for larger Sass projects. Note also that a JS API is required for integration which rules out the Dart version in its current form. The sass-loader package is used internally to process Sass files.

Have you performed speed comparisons with the Sass within your project between the JS version (with fibers) and the Dart version? Both can be run directly on the files via the command line. Benchmark data is always of use and interest to the team.

It's also important to consider that for the vast majority of applications, the processing of the JS code itself will consume the overwhelming majority of the build time. Poor stylesheet processing time can also be due to multiple or large imports of non-mixin/variable partials. This is especially relevant to component stylesheets as each is processed in an isolated context. For example, adding @import "node_modules/bootstrap/scss/bootstrap"; in each component's stylesheet would cause all of bootstrap to be processed multiple times and included in each component separately.

[jrood]

Thanks @clydin ! Yeah I'm experiencing performance issues, and in my case it seems over 70% of the time is spent on sass source maps.

Yes, I've done a speed comparison via the command line, and I've found that the the Dart version is about 4x faster than the JS version.

Putting Dart aside, the bigger issue in my case seems to be that the Angular CLI takes way longer than running directly via the command line. I had one large file (with many imports) that takes about 4 seconds to compile via ./node_modules/sass/sass <myfile>.scss <outputfile>.css, but the Angular CLI will sit on that same file for over 30 seconds (or over 2 minutes with source maps).

So this makes me wonder, what is the Angular CLI spending so much time on that it takes 30 seconds rather than 4 seconds?

[clydin]

Would you happen to have a log output from the troublesome builds? The webpack logs have a tendency to show the last action that was completed rather than what is currently being done.

[jrood]

A webpack log that's different form the console output during build? Do you know where I would find that?

[clydin]

The console output if that is what is showing the issue you've encountered.

[jrood]

For security reasons I can't post a whole console log, but basically I'll run

node --max_old_space_size=11152 ./node_modules/@angular/cli/bin/ng serve --hmr -ec --aot --configuration=local --verbose

there's a notice

NOTICE: (HMR) does not allow for CSS hot reload when used together with '--extract-css'.
11% building 14/14 modules 0 active[HPM] Proxy created:

Then many [HPM] entries
Then:

ℹ ｢wds｣: Project is running...
ℹ ｢wds｣: webpack output is served from /
ℹ ｢wds｣: 404s will fallback to //index.html

And then the issue it is spends a lot of time here:

53% building 360/362 modules 2 active ...<myfile>.scss

[jrood]

What I'm wondering is, when the Angular CLI is doing this (which takes ~30 seconds):

53% building 360/362 modules 2 active ...<myfile>.scss

Is that supposed to be the same work essentialy as this? (which takes ~4 seconds):

./node_modules/sass/sass <myfile>.scss <outputfile>.css

What else is the Angular CLI doing in this "building" step aside from sass compilation?

[jrood]

Sorry, I've let this issue get derailed a little with my particular situation. This ticket should remain focused on finding a way to use the DartVM executable rather than the pure-js version of dart-sass.

[clydin]

To address your previous question, every JS, TS, and stylesheet file (including third party dependencies) is considered a module. The displayed file is also the last active module and not necessarily what webpack is currently processing. From the log output there are also 2 active modules which means two different files were being processed when that status was updated and one of which being the one shown. That Sass file could also be unluckily processed right before a large JS file from a dependency; some of which can be megabytes in size.

As to using the Dart version directly, that would probably best be a feature request of sass-loader (https://github.com/webpack-contrib/sass-loader) as that is the package that handles all Sass processing within the CLI currently.

[jrood]

Thanks! I've opened an issue there: webpack-contrib/sass-loader#774

[clydin]

I'm going to close this issue as there does not appear to be anything actionable from an Angular CLI perspective. Any new versions of sass-loader will automatically be included upon release.
However, please re-open if the situation changes.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}