Add ability to pass dart-sass js api compiler options through @snowpack/plugin-sass

[jdb8]

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 and importer, 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 binary sass.

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 additional dartSassOptions 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 both compilerOptions as well as dartSassOptions).

If this sounds like something that would make sense, I'm happy to submit a PR.

[N0tExisting]

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.
Also it seems like every 'official' plugin uses the CLI instead of a JS API.

[jdb8]

@N0tExisting which breaking changes do you mean? Like if there are cli options currently being passed in which are not supported by the JS api?

As far as I can tell, https://www.npmjs.com/package/@snowpack/plugin-sass already seems suited to supporting this - it seems like an implementation detail that internally it uses the cli via execa rather than the js dart api.

Also it seems like every 'official' plugin uses the CLI instead of a JS API.

I guess I'm curious if this is an intentional design choice, since it seems like that's generally going to be suboptimal for a variety of reasons (two of which are relevant here: api drift and performance).