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

Vuetify requires Dart sass instead of node-sass #2239

Closed
dfabreguette opened this issue Aug 19, 2019 · 15 comments
Closed

Vuetify requires Dart sass instead of node-sass #2239

dfabreguette opened this issue Aug 19, 2019 · 15 comments

Comments

@dfabreguette
Copy link

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
Copy link
Member

Webpacker does not support the Dart sass package. One of the comments in this issue may help: #2235 (comment)

@gkatsanos
Copy link

gkatsanos commented Aug 26, 2019

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
Copy link
Member

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:

@jakeNiemiec jakeNiemiec added style loaders support Questions or unspecific problems labels Aug 26, 2019
@gkatsanos
Copy link

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, :

laravel-mix/laravel-mix#1832

@jakeNiemiec
Copy link
Member

image

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: sass/dart-sass#113

@jakeNiemiec jakeNiemiec added help wanted and removed support Questions or unspecific problems labels Aug 26, 2019
@jakeNiemiec jakeNiemiec changed the title Vuetify / sass instead of node_sass Vuetify requires Dart sass instead of node-sass Aug 26, 2019
@jakeNiemiec
Copy link
Member

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
Copy link

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

@dfabreguette
Copy link
Author

dfabreguette commented Feb 28, 2020

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
Copy link

@dfabreguette-ap I used #2235 (comment) this configuration and it worked as expected!
hope it can helps you

@1w2e3r4t5y66

This comment has been minimized.

@G-Rath
Copy link

G-Rath commented May 3, 2020

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
Copy link
Member

@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
Copy link

G-Rath commented May 5, 2020

@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
Copy link
Contributor

aried3r commented Jul 3, 2020

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
Copy link

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.

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

9 participants