Change build method to use dart sass instead of node-sass

[tcitworld]

This is a new feature. It is needed as node-sass is being depreciated, and compatibility between projects using legacy node-sass and projects using sass (Dart) is going to cause issues (such as #3333). By switching to the Dart version we can then better support it.

Proposed solution

It replaces node-sass with sass as the main way to build Bulma.

Tradeoffs

In the long term support for node-sass/libsass will have to be removed.

Testing Done

• Build the documentation and quick check for UI issues, and check that it doesn't reference node-sass as a preferred way to use Bulma anymore.
• Checked that the difference in the CSS files consists of very small changes (order changes)

Changelog updated?

Yes.

[jgthms]

This one is tricky because a lot of Bulma users still use something older than dart sass. It’s about 50% dart, 50% node or ruby sass. So while your project can use dart, it can still import Bulma in node sass. So 100% can use Bulma. But if Bulma switches to dart, Bulma would lose half of its users.

I’d like to use dart’s new features (I use it in projects that import Bulma), but it’s currently tricky to do the switch.

One solution would be to create 2 versions of Bulma. There could be a “bulma-dart” version of the framework, while “bulma” remains in node. And then do the switch at some point so that “bulma” would be in dart and “bulma-node” would exist as a legacy version.

This way 100% of the users could still use Bulma. They would only need to pick the correct version.

[tcitworld]

Wouldn't it be easier to bump to version to 1.x with this breaking behaviour and backport everything in 0.x versions? Instead of having distinct projects, if that's what you meant? Since it seems node-sass/libsass is going to be completely abandoned in the end.

[jgthms]

There is a plan of a v1 already in the pipelines. It’s not using dart, but actually it might be a good opportunity for that.

[service-paradis]

One solution would be to create 2 versions of Bulma. There could be a “bulma-dart” version of the framework, while “bulma” remains in node. And then do the switch at some point so that “bulma” would be in dart and “bulma-node” would exist as a legacy version.

I understand the point where you want to support the most users, but I'm not sure about this. Supporting 2 versions and directing people to use the correct version depending on their setup would be time consuming. Also, there are some projects out there that uses Bulma under the hood (Buefy for example). They will also need to offer 2 versions?

Asking people that uses Bulma with Dart to switch package could result with a loss too. It would make it easier to use Bulma for people that uses deprecated packages. Sounds wrong to me.

Wouldn't it be easier to bump to version to 1.x with this breaking behaviour and backport everything in 0.x versions? Instead of having distinct projects, if that's what you meant? Since it seems node-sass/libsass is going to be completely abandoned in the end.

There is a plan of a v1 already in the pipelines. It’s not using dart, but actually it might be a good opportunity for that.

I think this is a pretty good solution, but when is it planned? There are already a lot of people that uses the latest Dart package and have to ignore a lot of deprecation warnings. Maybe you could have a @next version short term (would be a good compromise with your idea of having a different project)?

[cokkto]

Agree with comment - keep 0.x version node_sass based, and make 1.x dart based. All current users will be able to continue using bulma, and when they eventually switch to dart, all what they need would be to switch to new major release

[tcitworld]

Do you still want this @jgthms ?

[lamka02sk]

We recently migrated back to node sass from dart sass, because dart sass is almost twice as slow. For us, 7s build times in dev mode were unacceptable. You should keep 0.x version node sass based as @cokkto suggested.
Let's hope there will be some progress on using dart vm executable with webpack very soon.

[stafyniaksacha]

We recently migrated back to node sass from dart sass, because dart sass is almost twice as slow. For us, 7s build times in dev mode were unacceptable. You should keep 0.x version node sass based as @cokkto suggested.
Let's hope there will be some progress on using dart vm executable with webpack very soon.

It may be because of using dart sass in js instead of dart vm : https://itnext.io/the-css-preprocessor-dilemma-node-sass-or-dart-sass-32a0a096572