-
-
Notifications
You must be signed in to change notification settings - Fork 423
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
Make it easier to prefer sass-embedded
over sass
#1180
Comments
But I am fine with
|
So feel free to send a PR |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Note
This could be a "when
sass-embedded
support is no longer experimental" modificationModification Proposal
My understanding is that
sass-embedded
can be considered like-for-like tosass
in terms of features and output i.e. assuming you can runsass-embedded
, you can always use it instead ofsass
and get the exact same compiled output (just faster); and the main reason thatsass
is a thing is becausesass-embedded
has more complicated OS requirements being a compiled binary.Thankfully
package.json
has a way of expressing dependencies which are desirable but OS restricted and so whose incompatibility with the current OS that is being installed on should not be considered a failure, allowing us to specifysass-embedded
as a dependency alongsidesass
as a fallback i.e.However it seems that
sass-loader
always favors loadingsass
, so in the above it'll never usesass-embedded
by default:sass-loader/src/utils.js
Lines 4 to 25 in bd65cba
Now this is technically documented (though in the context of
node-sass
) and we can explicitly change this usingimplementation
; however that would require us to have resolving logic in our webpack config across all applications and projects.I figure
sass
was preferred back when it was justnode-sass
because the latter is technically deprecated and is not like-for-like, but maybe it's time to consider revising the default implementation order with the introduction ofsass-embedded
?I think there are a few ways this could be done which would all be fine:
sass-embedded
firstimplementation
on the lines ofprefer-sass-embedded
(or a dedicatedpreferSassEmbedded
boolean option)sass-embedded,sass
(though this is probably a bit much given there's not expected to be yet another sass implementation...)Expected Behavior / Situation
sass-loader
preferssass-embedded
by default, allowing us to manage providing the fastest sass implementation possible for the host, such as withoptionalDependencies
or installingsass-embedded
in a dedicated step during building our docker images, provisioning servers, etc.Actual Behavior / Situation
sass-loader
loadssass
by default, ignoringsass-embedded
Please paste the results of
npx webpack-cli info
here, and mention other relevant informationThe text was updated successfully, but these errors were encountered: