Scripts: Consider replacing node-sass with Dart SASS

[gziolo]

Description

Related to #21730 that added support for CSS imports in JavaScript files to start and build scripts in @wordpress/scripts package.

In #21730 (comment), @aduth raised the following issue related to node-sass package used:

I hope we don't come to regret foisting this troublesome dependency upon consumers of @wordpress/scripts

Indeed, we had many reports when people struggled with this package when upgrading Node.js version because it requires compilation.

@yscik suggested the following:

I would suggest changing this to Dart SASS (sass package). It's the primary implementation for SASS, and saves contributors all the native compilation trouble node-sass brings. sass-loader picks it up without any additional configuration.

If we decide to go this route, we should ensure we use the same approach in Gutenberg project consistently.

[ocean90]

This might be another use case for using the npm alias feature:
npm install --save-dev node-sass@npm:sass will add "node-sass": "npm:sass@^1.26.7".

[Ruzgfpegk]

Another issue is that, to be able to use the... @use directive, Dart Sass is the only choice :

Only Dart Sass currently supports @use. Users of other implementations must use the @import rule instead.

But @import is deprecated...

The Sass team discourages the continued use of the @import rule. Sass will gradually phase it out over the next few years, and eventually remove it from the language entirely. Prefer the @use rule instead.

The post that helped me understand why my perfectly valid SCSS didn't work when in the block scaffold:
https://carterbancroft.com/sass-and-webpack/

According to its author, only the sass package works and not the (seemingly outdated) dart-sass one.

[gziolo]

There is now PR from @yscik opened that might resolve the issue. #25628 needs review and testing.

[jakeparis]

@gziolo Should this still have the [Status] In Progress label even though it's closed?

The latest version of @wordpress/scripts still is pulling down node-sass, but #25628 makes it look like dart-sass has already been switched to. Is there something I'm missing to get my local wordpress/scripts to use dart-sass instead?

[gziolo]

It was fixed but we didn't publish to npm yet. It's planned for next week.

Is this status confusing. I think we never remove In Progress label after closing the issue, but we could automate it.

[jakeparis]

Removing the In Progress would certainly help bystanders when looking back over old issues to figure out what's going on!

[gziolo]

@annezazu, can we include it in one of the project management issues you recently created? 😃

[annezazu]

Great idea. I'll open one up now!

[sandrab]

It was fixed but we didn't publish to npm yet. It's planned for next week.

Is this status confusing. I think we never remove In Progress label after closing the issue, but we could automate it.

Adding to the confusion (at least, for me) is that the npm release does not always include all closed issues at that time. For example, this issue was closed on Oct 28. When I saw a new npm release on Oct 30, I wrongly assumed that this issue would be fixed there. It took me a while to find out it was not and that I should look at the written changelog instead of the commit history. Once you know this, it is logical, but we might make this more clear for people like me who do not have much insight in the whole release process.