Replies: 1 comment 1 reply
-
I'm not sure, but this would probably be better fixed by its own plugin, as the amount of breaking changes would be just too big. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi! I'm working on a codebase that uses some custom Sass options via the JS api (https://sass-lang.com/documentation/js-api), for example
functions
andimporter
, but I noticed that the existing implementation of@snowpack/plugin-sass
only supports arguments that can be converted to CLI options.I'm curious if there was a reason for this, since the plugin already direct-deps dart-sass and is written in js, which seems like a perfect opportunity to run sass directly in js. This seems like it would also potentially be a slight perf boost since you then avoid repeated calls to
execa
which are currently required to shell out to the binarysass
.Assuming there isn't a reason for doing this that I'm missing, my proposal would be to switch over to calling the
sass
api through js, removing the execa call + the logic needed to convert camelCase options to kebab-case. If backwards compatibility is a concern, we could keep the existing behaviour and add an additionaldartSassOptions
or other such options object which would be passed directly to the api if provided (although I haven't yet thought about what would happen if a user provides bothcompilerOptions
as well asdartSassOptions
).If this sounds like something that would make sense, I'm happy to submit a PR.
Beta Was this translation helpful? Give feedback.
All reactions