Webpacker: Vuetify requires Dart `sass` instead of `node-sass`

[dfabreguette-ap]

Hey !
I'm having this issue installing vuetify on a rails app.
https://vuetifyjs.com/en/getting-started/frequently-asked-questions#invalid-css-after-content-expected-was-material-light
Looking at my yarn.lock file, I realised node_sass was a Rails Webpacker dependency.
Any chance someone had same issue and knows how to either remove node_sass dependency OR force wepack to use sass lib ?

[jakeNiemiec]

Webpacker does not support the Dart sass package. One of the comments in this issue may help: https://github.com/rails/webpacker/issues/2235#issuecomment-521694209

[gkatsanos]

Webpacker should make an effort to be more agnostic for things like loaders etc and accept everything from an external config value or parameter. It's a continuous fight to override it's baked-in configuration. I understand it's built for a particular audience but at least let's document the possibility to delete the existing configuration :)

PS: it appears node-sass is not actively maintained and dart-sass is a better solution.

[jakeNiemiec]

it appears node-sass is not actively maintained and dart-sass is a better solution.

What leads you to say that? I could not find anything to that effect:

• https://github.com/sass/node-sass
• https://twitter.com/nodesass

[gkatsanos]

I stand corrected. It's slowly losing momentum. Node sass always had issues, its big bulky and has dependencies. There's also the infamous rebuild flag needed when you change OS. For more info, :

https://github.com/JeffreyWay/laravel-mix/issues/1832

[jakeNiemiec]

It's slowly losing momentum.

Agreed, but very slowly. 🐢

I would rather have a quicker solution at the cost of standard maintenance. Node Sass is just a wrapper around LibSass, the native C++ implementation of Sass. This is why it needs to be built specifically to your OS.

Dart Sass, is reportedly up to 3x slower since you're computing things from within a VM: https://github.com/sass/dart-sass/issues/113

[jakeNiemiec]

Just stopping by to share a growing justification for switching to dart sass: https://github.com/sass/sass/blob/master/accepted/module-system.md#timeline

[tomocrafter]

I want to use vuetify on the rails with webpacker.
Is there any example of project or workaround?

[dfabreguette-ap]

I want to use vuetify on the rails with webpacker.
Is there any example of project or workaround?

@tomocrafter I simply used compiled CSS version, and overides.
Hoping I can use sass variables soon !

[tomocrafter]

@dfabreguette-ap I used https://github.com/rails/webpacker/issues/2235#issuecomment-524527397 this configuration and it worked as expected!
hope it can helps you

[1w2e3r4t5y66]

2239

[G-Rath]

Just a heads up that a new vulnerability in yargs-parser has surfaced, which is pulled in by node-sass by a friend of a friend, who can't be bumped due to node versions, and so will remain (indirectly) "in" node-sass until they release v5.

Meanwhile sass does not depend on any packages with known vulnerabilities.

[jakeNiemiec]

@G-Rath It was patched, but it was never a threat since node-sass never touches the browser anyway:

If that CLI runner is not deployed to your servers but kept as a dev requirement used in your build process, your prod servers will be fine.

[G-Rath]

@jakeNiemiec yeah I just saw that, which is awesome! 🎉😄🥳

it was never a threat since node-sass never touches the browser anyway

That's the theory, but ultimately it's still an known vulnerability, and so still has some risk, not all of which is development based ("highly secure" government platforms like CWP are a great example - every package that goes in gets audited and weighed up; that affects companies like mine downstream as we have to comply with their strict requirements & regulations).

Additionally since it's allowed by the version constraints, package managers would be entirely within their rights to decide to use the insecure version instead of a later one if it was the version that could be most deduplicated (i.e I have node-sass + another cli tool that does get called & uses yargs-parser).

That second one is a lot more theoretical given how old this version of yargs/yargs-parser is, but it's still valid.

But I've got no major dog in this fight: while I think it would be good in the long run to allow developers to use either or, and that this is a good example to why it would be a benefit, as you say it's no longer a threat so 🥳

[aried3r]

sass-loader now also prefers dart-sass and recommends switching.

Would there be any breaking change for users of webpacker if this change was done internally?

[tegandbiscuits]

Just wanted to mention that #2716 replaces node-sass with sass.

I'm not sure when it'll actually go out to NPM, but I was able to just replace @rails/webpacker with the github repo.