Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to use the DartVM executable rather than the pure-js version of dart-sass. #774

Open
jrood opened this issue Oct 31, 2019 · 68 comments

Comments

@jrood
Copy link

jrood commented Oct 31, 2019

  • Operating System: OSX
  • Node Version: 10.16.3
  • NPM Version: 6.11.3
  • webpack Version: 4.39.2
  • sass-loader Version: 7.1.0

Feature Proposal

Currently, the only options for implementation are node-sass and the pure-js version of dart-sass.
There should be an option to use the fast DartVM executable version of dart-sass.

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

Feature Use Case

For projects that have a large codebase of sass files that need to be compiled and performance is important.

@alexander-akait
Copy link
Member

alexander-akait commented Nov 5, 2019

Make sense, feel free to send a PR

@rowanbeentje
Copy link

rowanbeentje commented Oct 21, 2020

https://github.com/sass/embedded-host-node, currently in Alpha, may be the easiest way to achieve this!

@alexander-akait
Copy link
Member

alexander-akait commented Oct 21, 2020

Yep, but right now it is not easy

@strarsis
Copy link

strarsis commented Mar 19, 2021

+1!

@denizsokullu
Copy link

denizsokullu commented Jan 3, 2022

@alexander-akait https://github.com/sass/embedded-host-node is getting close to a usable beta that includes custom importers and many other features that the sass-loader relies on. What do you think?

@alexander-akait
Copy link
Member

alexander-akait commented Jan 3, 2022

Unfortunately, I have not looked at this for a long time, if you have any ideas how we can integrate this now, you can send it, I will be glad any help

@alexander-akait
Copy link
Member

alexander-akait commented Jan 3, 2022

It will be easy if they have docs 😄 @nex3 Can we try it to integrate and test or is it still very young?

@nex3
Copy link
Contributor

nex3 commented Jan 4, 2022

As soon as sass/embedded-host-node#94 lands, the embedded host will fully support the new JS API. I'll be cutting a beta release at that point that you can test against.

@rowanbeentje
Copy link

rowanbeentje commented Jan 6, 2022

Just to mention that @nex3 has now merged that PR and cut the beta release: https://github.com/sass/embedded-host-node/releases/tag/1.0.0-beta.8 . I'm excited about this!

@alexander-akait
Copy link
Member

alexander-akait commented Jan 7, 2022

@nex3 Hi, where we can find docs about usage? Thanks

@nex3
Copy link
Contributor

nex3 commented Jan 7, 2022

It's all documented at https://sass-lang.com/documentation/js-api.

Edit: I realized you probably meant docs specifically about using embedded-host-node. We don't have official docs yet, but it's really just a drop-in replacement for the sass package, so you should be able to add it to your package.json and go from there.

@alexander-akait
Copy link
Member

alexander-akait commented Jan 8, 2022

I tried to adopt https://github.com/sass/embedded-host-node locally, and it works good for me, I'll try it here and maybe make a release, perf is almost the same

@alexander-akait
Copy link
Member

alexander-akait commented Jan 8, 2022

#1011

@alexander-akait
Copy link
Member

alexander-akait commented Jan 8, 2022

@nex3 Small feedback:

  1. Function is not work:

Example (if you change sass-embedded on sass/node-sass, all works fine):

var sass = require("sass-embedded");

sass.render(
  {
    data: "#{headings(2,5)} { color: #08c; }\n",
    functions: {
      "headings($from: 0, $to: 6)": (from, to) => {
        const f = from.getValue();
        const t = to.getValue();
        const list = new sass.types.List(t - f + 1);
        let i;

        for (i = f; i <= t; i++) {
          list.setValue(i - f, new sass.types.String(`h${i}`));
        }

        return list;
      },
    },
  },
  function (err, result) {
    if (err) {
      // `err - Error: expected selector.` for `sass-embedded`
      console.log(err);
      
      return;
    }
    console.log(result.css.toString());
  }
);
  1. Importers broken, I tried old format (i.e. just function) and new format (i.e. { canonicalize(url) {}, load(canonicalUrl) {} } ), both is not working, code is simple:
@import import-with-custom-logic

We still use render function to keep compatibility with node-sass/sass (dart), maybe problem with this, I don't found docs about it, but in types they are exists

  1. includePaths doesn't work, we have very simple test where we provide includePaths to sass and just use @import "import-from-included-path";

@denizsokullu
Copy link

denizsokullu commented Jan 8, 2022

https://github.com/sass/embedded-host-node/blob/main/lib/src/legacy.ts does not seem to have some of the specification included as it masks most of the options before calling the new api compile. @alexander-akait you could try to drop the legacy render method in favor of compileAsync?

@alexander-akait
Copy link
Member

alexander-akait commented Jan 10, 2022

Yep, we can do it, just interesting why it doesn't work with legacy, because types exist

@alexander-akait
Copy link
Member

alexander-akait commented Jan 10, 2022

hm, I was wrong, if we change render on compileStringAsync old legacy importers will not work, it is breaking change for us, because many developers still use them...

@alexander-akait
Copy link
Member

alexander-akait commented Jan 10, 2022

I tried to switch on modern API, but docs are very bad and no examples (spent a lot of time to understand how new API works), so it requires more time than I think...

@alexander-akait
Copy link
Member

alexander-akait commented Jan 10, 2022

Spent two days on this stuff and no luck, the new importer api is not usable and docs are very bad 😞 , https://sass-lang.com/documentation/js-api/interfaces/Importer,

The problem - we don't have prev in new importer API (as we have in old), so we don't know where should we resolve your import/use (you can have @import "variables"; in different files and we should know where it was requested from), we can use the url option, but it will work only for top file and nested imports is no possible to resolve

@alexander-akait
Copy link
Member

alexander-akait commented Jan 10, 2022

@nex3 Why prev was removed from importers https://sass-lang.com/documentation/js-api/modules#LegacySyncImporter?

Without file where it was requested we can't perform resolving, we don't know context so we don't have where we should start to resolve...

@nex3
Copy link
Contributor

nex3 commented Jan 10, 2022

Yep, we can do it, just interesting why it doesn't work with legacy, because types exist

We implemented the new API for sass-embedded first. Note that it's currently only a beta release, so it doesn't have everything we plan to add. I'm currently working on adding support for the legacy JS API.

hm, I was wrong, if we change render on compileStringAsync old legacy importers will not work, it is breaking change for us, because many developers still use them...

Correct, old importers won't work with the new JS API and vice versa. Old importers are actually quite difficult to make efficient because they don't play nicely with the concept of "canonical URLs", which was one of the motivations of moving to a new API in the first place.

I tried to switch on modern API, but docs are very bad and no examples (spent a lot of time to understand how new API works), so it requires more time than I think...

I wrote all those docs, so if you can provide specific ways they could be more helpful or additional examples you'd like to see I'd be happy to improve them.

The problem - we don't have prev in new importer API (as we have in old), so we don't know where should we resolve your import/use (you can have @import "variables"; in different files and we should know where it was requested from), we can use the url option, but it will work only for top file and nested imports is no possible to resolve

This would have been a good thing to bring up when we asked for feedback. In this case, though, there's a good reason for the behavior. There are a few invariants we want to make sure all importers abide by, in order to allow the Sass compiler to make important optimizations (like only loading each stylesheet once) and to ensure that users can consistently reason about loads:

  1. There must be a one-to-one mapping between (absolute) canonical URLs and stylesheets. This means that even when a user loads a stylesheet using a relative URL, that stylesheet must have an absolute canonical URL associated with it and loading that canonical URL must return the same stylesheet. This means that any stylesheet can always be loaded using its canonical URL.

  2. Relative URLs are resolved like paths, so for example within scheme:a/b/c.scss the URL ../d should always be resolved to scheme:a/d.

  3. Loads relative to the current stylesheet always take precedence over loads from the load path (including virtual load paths exposed by importers), so if scheme:a/b/x.scss exists then @use "x" within scheme:a/b/c.scss will always load.

The old importer API didn't guarantee any of these invariants. An importer could use the prev parameter to add stylesheets that could only be imported as relative URLs, thus violating (1). Or it could ignore the prev parameter completely and break relative URLs, violating (2) and (3).

Rather than pushing all the complexity of handling these invariants onto importer authors like the old API, the new API is designed so that these invariants can't be violated. To quote the documentation:

Relative loads in stylesheets loaded from an importer are handled by resolving the loaded URL relative to the canonical URL of the stylesheet that contains it, and passing that URL back to the importer's canonicalize method. For example, suppose the "Resolving a Load" example above returned a stylesheet that contained @use "mixins":

  • The compiler resolves the URL mixins relative to the current stylesheet's canonical URL db:foo/bar/baz/_index.scss to get db:foo/bar/baz/mixins.
  • It calls canonicalize with "db:foo/bar/baz/mixins".
  • canonicalize returns new URL("db:foo/bar/baz/_mixins.scss").

Because of this, canonicalize must return a meaningful result when called with a URL relative to one returned by an earlier call to canonicalize.

For your use-case, it's probably easiest to use a FileImporter: this allows you to redirect a Webpack-style load to a specific file, but then automatically handles any relative loads from there without you needing to intervene at all. This is also more efficient, since it saves a round-trip from the compiler for each relative loads.

@alexander-akait
Copy link
Member

alexander-akait commented Feb 18, 2022

@nex3 Can you look at the latest my report, because we have reports from other developers too - #1028, more repro - https://github.com/francescocaveglia/sass-loader-bug

@nex3
Copy link
Contributor

nex3 commented Feb 18, 2022

Working on a fix. In the meantime, you should be able to work around it by passing importers: undefined instead of importers: [].

@nex3
Copy link
Contributor

nex3 commented Feb 18, 2022

sass/embedded-host-node#114

@alexander-akait
Copy link
Member

alexander-akait commented Feb 19, 2022

@nex3 Can you look at second example #774 (comment) (the same problem - https://github.com/francescocaveglia/sass-loader-bug), it is more important, because developers can't compile bootstrap 5, thanks

@alexander-akait
Copy link
Member

alexander-akait commented Feb 22, 2022

Confirmed - source map generation fixed #1030

Hope @nex3 will find time in near future to fix problems with custom importer - #774 (comment) and second example in #774 (comment)

After this I want to say it it safe to migrate on sass-embedded and get perf improvement

@nex3
Copy link
Contributor

nex3 commented Feb 23, 2022

I have a PR out: sass/embedded-host-node#114

@alexander-akait
Copy link
Member

alexander-akait commented Feb 24, 2022

@nex3 I'm afraid I've confused you a bit, could you run, that is another problem:

Can you run locally:

const sassEmbedded = require("sass-embedded");

(async () => {
  try {
    await new Promise((resolve, reject) => {
      sassEmbedded.render(
          {
            data:
                '@use "util";\n' +
                '/* @use "~module"; */\n' +
                '//@use "~module" as module2;\n' +
                '/* @use "~another"; */\n' +
                '//@use "~another" as another;\n' +
                '/* @use "~@org/style"; */\n' +
                "// Should prefer `scss`\n" +
                '@use "@org/style";\n',
            file: "/home/evilebottnawi/IdeaProjects/sass-loader/test/scss/uses.scss",
            importer: [
              function (prev, url, done) {
                console.log("HERE");

                done({ file: url });
              },
            ],
          },
          (error, result) => {
            if (error) {
              reject(error);

              return;
            }

            console.log(result);

            resolve();
          }
      );
    });
  } catch (error) {
    console.log(error);
  }
})();

Output:

Error: Error: TypeError: Cannot read property 'url' of undefined
  ╷
8 │ @use "@org/style";
  │ ^^^^^^^^^^^^^^^^^
  ╵
  test/scss/uses.scss 8:1  root stylesheet
    at handleCompileResponse (/path/to/sass-loader/node_modules/sass-embedded/dist/lib/src/compile.js:213:15)
    at compileRequestAsync (/path/to/sass-loader/node_modules/sass-embedded/dist/lib/src/compile.js:101:16)
    at processTicksAndRejections (internal/process/task_queues.js:97:5) {
  status: 1,
  formatted: "Error: TypeError: Cannot read property 'url' of undefined\n" +
    '\u001b[34m  ╷\u001b[0m\n' +
    '\u001b[34m8 │\u001b[0m \u001b[31m@use "@org/style"\u001b[0m;\n' +
    '\u001b[34m  │\u001b[0m \u001b[31m^^^^^^^^^^^^^^^^^\u001b[0m\n' +
    '\u001b[34m  ╵\u001b[0m\n' +
    '  test/scss/uses.scss 8:1  root stylesheet',
  toString: [Function: toString],
  line: 8,
  column: 1,
  file: '/path/to/sass-loader/test/scss/uses.scss'
}

As you can see we have another problem here:

Error: Error: TypeError: Cannot read property 'url' of undefined

If you try to compile webpack 5 using sass-loader you will faced with it. It can be critical for developers.

Even more it doesn't run importer.

Thanks for help!

@nex3
Copy link
Contributor

nex3 commented Feb 24, 2022

@alexander-akait with sass/embedded-host-node#114 patched in I see:

HERE
Error: Error: Can't find stylesheet to import.
  ╷
1 │ @use "util";
  │ ^^^^^^^^^^^
  ╵
  /home/evilebottnawi/IdeaProjects/sass-loader/test/scss/uses.scss 1:1  root stylesheet
    at handleCompileResponse (/home/nweiz/goog/sass/host/dist/lib/src/compile.js:213:15)
    at compileRequestAsync (/home/nweiz/goog/sass/host/dist/lib/src/compile.js:101:16)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  status: 1,
  formatted: "Error: Can't find stylesheet to import.\n" +
    '\x1B[34m  ╷\x1B[0m\n' +
    '\x1B[34m1 │\x1B[0m \x1B[31m@use "util"\x1B[0m;\n' +
    '\x1B[34m  │\x1B[0m \x1B[31m^^^^^^^^^^^\x1B[0m\n' +
    '\x1B[34m  ╵\x1B[0m\n' +
    '  /home/evilebottnawi/IdeaProjects/sass-loader/test/scss/uses.scss 1:1  root stylesheet',
  toString: [Function: toString],
  line: 1,
  column: 1,
  file: '/home/evilebottnawi/IdeaProjects/sass-loader/test/scss/uses.scss'
}

@alexander-akait
Copy link
Member

alexander-akait commented Feb 24, 2022

@nex3 thanks, I will test it tomorrow, because it is strange, it means something different in resolving (maybe bug?), I will check and provide report

@alexander-akait
Copy link
Member

alexander-akait commented Feb 25, 2022

@nex3 updated and check (sass-embedded@1.49.9), still broken (I can reproduce it using bootstrap 5 too).

There is example of repo with bootstrap 5 https://github.com/francescocaveglia/sass-loader-bug, steps are easy.

We have:

@import 'bootstrap-sass/assets/stylesheets/bootstrap/variables';
@import 'bootstrap-sass/assets/stylesheets/bootstrap/mixins';
@import 'bootstrap-sass/assets/stylesheets/bootstrap/scaffolding';

.selector {
  color: blue;
}

I tried to debug - we call our importer on:

@import 'bootstrap-sass/assets/stylesheets/bootstrap/variables';
@import 'bootstrap-sass/assets/stylesheets/bootstrap/mixins';

But after and inside we don't call importer on @import/@use.

On sass-loader side we have (debug output):

bootstrap-sass/assets/stylesheets/bootstrap/variables
/path/to/sass-loader-bug/node_modules/bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss

bootstrap-sass/assets/stylesheets/bootstrap/mixins
/path/to/sass-loader-bug/node_modules/bootstrap-sass/assets/stylesheets/bootstrap/_mixins.scss

As you can see we don't run importer on @import inside _mixins.scss and after too.

Looks like we don't call importer on any nested @import/@use, it works fine on first level @import/@use, but everything inside no longer works.

And due to this we have - SassError: TypeError: Cannot read property 'url' of undefined, sass-embedded just don't run our custom importer and wait return.

I tried to reproduce without sass-loader:

  • install npm i bootstrap-sass
  • create file:
const path = require("path");

const sassEmbedded = require("sass-embedded");

(async () => {
  try {
    await new Promise((resolve, reject) => {
      sassEmbedded.render(
        {
          data:
            "@import 'bootstrap-sass/assets/stylesheets/bootstrap/variables';\n" +
            "@import 'bootstrap-sass/assets/stylesheets/bootstrap/mixins';\n" +
            "@import 'bootstrap-sass/assets/stylesheets/bootstrap/scaffolding';",
          file: "/home/evilebottnawi/IdeaProjects/sass-loader/index.scss",
          importer: [
            function (original, prev, done) {
              console.log("RESOLVE ", original);

              const dirname = path.dirname(original);
              const basename = path.basename(original);
              const found = path.resolve(
                __dirname,
                "node_modules",
                dirname,
                `_${basename}.scss`
              );

              console.log("RESOLVED ", found);

              done({ file: found });
            },
          ],
        },
        (error, result) => {
          if (error) {
            reject(error);

            return;
          }

          console.log(result);

          resolve();
        }
      );
    });
  } catch (error) {
    console.log(error);
  }
})();
  • run it

output:

RESOLVE  bootstrap-sass/assets/stylesheets/bootstrap/variables
RESOLVED  /path/to/sass-loader/node_modules/bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss
DEPRECATION WARNING: Using / for division outside of calc() is deprecated and will be removed in Dart Sass 2.0.0.

Recommendation: math.div($grid-gutter-width, 2) or calc($grid-gutter-width / 2)

More info and automated migrator: https://sass-lang.com/d/slash-div

    ╷
368 │ $navbar-padding-horizontal:        floor(($grid-gutter-width / 2)) !default;
    │                                           ^^^^^^^^^^^^^^^^^^^^^^
    ╵
    bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss 368:43  @import
    index.scss 1:9                                                      root stylesheet

DEPRECATION WARNING: Using / for division outside of calc() is deprecated and will be removed in Dart Sass 2.0.0.

Recommendation: math.div($navbar-height - $line-height-computed, 2) or calc(($navbar-height - $line-height-computed) / 2)

More info and automated migrator: https://sass-lang.com/d/slash-div

    ╷
369 │ $navbar-padding-vertical:          (($navbar-height - $line-height-computed) / 2) !default;
    │                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ╵
    bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss 369:37  @import
    index.scss 1:9                                                      root stylesheet

RESOLVE  bootstrap-sass/assets/stylesheets/bootstrap/mixins
RESOLVED  /path/to/sass-loader/node_modules/bootstrap-sass/assets/stylesheets/bootstrap/_mixins.scss
Error: Error: TypeError: Cannot read property 'url' of undefined
  ╷
3 │ @import 'bootstrap-sass/assets/stylesheets/bootstrap/scaffolding';
  │         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ╵
  index.scss 3:9  root stylesheet
    at handleCompileResponse (/path/to/sass-loader/node_modules/sass-embedded/dist/lib/src/compile.js:213:15)
    at compileRequestAsync (/path/to/sass-loader/node_modules/sass-embedded/dist/lib/src/compile.js:101:16)
    at processTicksAndRejections (internal/process/task_queues.js:97:5) {
  status: 1,
  formatted: "Error: TypeError: Cannot read property 'url' of undefined\n" +
    '  ╷\n' +
    "3 │ @import 'bootstrap-sass/assets/stylesheets/bootstrap/scaffolding';\n" +
    '  │         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n' +
    '  ╵\n' +
    '  index.scss 3:9  root stylesheet',
  toString: [Function: toString],
  line: 3,
  column: 9,
  file: '/path/to/sass-loader/index.scss'
}

As you can see there is the same problem - we don't call importer on @import inside bootstrap-sass/assets/stylesheets/bootstrap/mixins (i.e. /path/to/sass-loader/node_modules/bootstrap-sass/assets/stylesheets/bootstrap/_mixins.scss) and you can see the same error - Error: Error: TypeError: Cannot read property 'url' of undefined

@alexander-akait
Copy link
Member

alexander-akait commented Mar 10, 2022

@nex3 friendly ping

@jmbastidas
Copy link

jmbastidas commented Mar 22, 2022

@nex3 hello, do you have news on this?

@alexander-akait
Copy link
Member

alexander-akait commented Apr 22, 2022

Looks like fixed, I will test

@alexandernst
Copy link

alexandernst commented Apr 22, 2022

Can you point to the commit which fixed this, please?

@alexander-akait
Copy link
Member

alexander-akait commented Apr 22, 2022

All tests passed #1044

@Clarkkkk
Copy link

Clarkkkk commented Apr 25, 2022

I want to do release today, there are some bugs with source maps and @use (edge case) in sass-embedded (I will ping nex3 here and report about them here, we can't fix them in sass-loader), also I implement api: "modern" | "legacy", but it is experimental and currently modern API doesn't support built-in webpack resolver, i.e. all styles from node_modules will be not loaded, but you can use loadPaths if you have simple project, if you rely on the sass field in package.json/aliases or somethings more complex it will not work with modern API, unfortunately to solve it we need to improve some things on sass side.

Benchmarks (locally, bootstrap 5 latest):

node-sass#render x 2.70 ops/sec ±1.36% (18 runs sampled)
dart-sass#render x 0.41 ops/sec ±12.03% (7 runs sampled)
sass-embedded#render x 3.95 ops/sec ±0.74% (24 runs sampled)
Fastest is sass-embedded#render

I think words are unnecessary here

I simply add implemetation: 'embedded-sass' and saw a speed regression (build time from 1min 12s to 1min 40s). Did I miss something?

Both sass-loader and embedded-sass are latest version.
Device: M1 Mac mini
OS: Mac OS 12.3.1
Node: 16.11.1

@alexander-akait
Copy link
Member

alexander-akait commented Apr 25, 2022

@Clarkkkk hard to say, how you profile?

@Clarkkkk
Copy link

Clarkkkk commented May 9, 2022

@Clarkkkk hard to say, how you profile?

The config is like:

    entry: './src/index.js',
    mode: 'production',
    output: {
        filename: 'main.js',
        path: path.resolve(__dirname, 'dist'),
    },
    module: {
        rules: [{
            test: /\.(sa|sc)ss$/,
            use: [
                {
                    loader: MiniCssExtractPlugin.loader
                },
                {
                    loader: 'css-loader',
                    options: {
                        modules: {
                            exportLocalsConvention: 'camelCase'
                        },
                    }
                },
                'postcss-loader',
                {
                    loader: 'sass-loader',
                    options: {
                        sassOptions: {
                            charset: false
                        },
                        implementation: require('sass-embedded')
                    }
                }
            ]
        }]
    },
    plugins: [
        new MiniCssExtractPlugin(),
        new CleanWebpackPlugin(),
    ],

But when I use the same config on a simple bootstrap example, sass-embedded is indeed faster. It is not easy to reproduce the speed regression issue.

@alexander-akait
Copy link
Member

alexander-akait commented May 9, 2022

@Clarkkkk maybe you can profile, I file loke regression on sass-embedded side

@Clarkkkk
Copy link

Clarkkkk commented May 10, 2022

@Clarkkkk maybe you can profile, I file loke regression on sass-embedded side

I'm sorry, but what do you mean 'profile'?

@alexander-akait
Copy link
Member

alexander-akait commented May 10, 2022

Profile code and undestand where it you have perf problems, https://nodejs.org/en/docs/guides/simple-profiling/

@Clarkkkk
Copy link

Clarkkkk commented May 11, 2022

Oh, I see.

The original log file is quite large (over 100 M), here is the processed txt file: https://1drv.ms/t/s!AqaKW1-15JGra_rU4o09K44A04E. (It generates 12 files after compilation, and this is one that includes sass-embedded. If you need the others, I can provide them as well)

@alexander-akait
Copy link
Member

alexander-akait commented May 11, 2022

@Clarkkkk I think better to open an issue in sass-embedded repo, we can't fix it here

@AprilArcus
Copy link

AprilArcus commented Aug 20, 2022

I happened to give sass-embedded a try, and found that performance actually degraded by a small but statistically significant amount. Results are with an empty cache and four thread-loader workers.

mean 95% CI
JS (sass) 63.6s ± 0.3s
AOT (sass-embedded) 66.1s ± 0.4s

I was surprised by this based on the results other folks have been reporting. Please let me know if you'd like me to do more benchmarking or profiling; I'm happy to help if I can.

@nex3
Copy link
Contributor

nex3 commented Aug 23, 2022

@AprilArcus That's expected if you're compiling many small CSS files. See sass/sass#3296.

@tannera
Copy link

tannera commented Sep 6, 2022

@AprilArcus That's expected if you're compiling many small CSS files. See sass/sass#3296.

Unfortunately it's a common use case to have many small sass files for those using CSS Modules in a large React codebase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests