Hei William, thanks a lot for pushing this!

I played around with your branch and wasn't able to @use or @import from node_modules like

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

Error in plugin "sass"
Message:
    path/to/my/file.scss
Can't find stylesheet to import.

(it's an old project, don't ask…).

I have passed 'node_modules' as an includePath. Have you by any chance tested a similar use case and figured it out?

includePath is part of the legacy API from what I can tell (the one this PR migrates away from).
You may need to try loadPaths @polarbirke

If that doesn't work, we use a ~ prefix for node_modules imports in fremtind/jokul and handle that with an importer. For reference, we use patch-package and this patch while waiting for this PR to land.

Thanks, that does it! 👍

Unfortunately the compile time I see is still about twice as high when compared to the legacy node-sass setup. Did I overestimate the benefits of this PR / am I missing an additional toggle to gain speed?

Speed benefits will probably depend on you also using sass-embedded instead of the regular sass package to compile. Can’t promise any miracles, but it should be a bit faster @polarbirke .

I just tested this branch with sass-embedded and it compiles .scss files just fine. Sourcemaps also work when using gulp v4's built-in sourcemaps support (not the deprecated gulp-sourcemaps project.)

Not surprisingly, the node-sass-glob-importer didn't work, but I don't think it has been updated to use the new JS API.

node-sass-glob-importer is not updated to support the new JS API, no. I looked into¹ whether the functionality could be ported to the new Importer API, but it seems difficult – especially with the new module system.

One of the goals of @use and @forward in my understanding is for module imports to be more explicit and predictable. If you depend on one or more complex importers for the old syntax I would consider migrating away, or at least not use it for new code.

I looked into whether the functionality could be ported to the new Importer API, but it seems difficult

Indeed. I only use the globber as a convenience for importing all my mixins with one line instead of one-by-one. If someone wanted to implement a new globber, I think the simpler FileImporter API would be a better fit than the full Importer API.

To be clear, I do not consider a lack of a globber a show stopper for this PR. I'm using this branch now for a new project and hope it will be merged soon.

Thanks for your work, @wkillerud!

Would love to see this merged. Have tested myself and is working and I am using it succesfully with sass-embedded. Notes are.

• Importers need to be upgraded to use the new importer API.
• Sourcemaps seem to use absolute rather than relative paths which can be somewhat mitigated with some sourcemap source modification

I just tested this, and it works great, I needed to switch to the newer compile, to get settings such as quiet, quietDeps and silenceDeprecations working, and it works nicely.

@dlmanning Hi, is it possible to merge this PR?

@dlmanning is there any chance to merge this ? It would solve #870 and #867

Maybe @xzyfer is able to help out here, considering they published the last release in 2021?

I didn't have that much patience, so I just forked https://github.com/wkillerud/gulp-sass/tree/feat/migrate-to-v2 the code itself is "pretty simple" as its a wrapper that passes the info to sass.

But this should surely be released.

Thanks for the tag. I don't actively follow this repo. Will take a look and aim to get a release out this week now that node-sass is deprecated.

Any movement in there? Still seeing lot of

Deprecation Warning: The legacy JS API is deprecated and will be removed in Dart Sass 2.0.0.

More info: https://sass-lang.com/d/legacy-js-api

on my build pipeline

@xzyfer Any updates on this?

Hey @dlmanning

Any chance of having this merged? Thanks.

Edit: maybe @xzyfer is at charge now?

Thanks for all your effort @wkillerud. I'm very sorry for the delay in getting this released.