Add WASM compilation target

[dmichon-msft]

Now that Dart supports WASM as a compilation target, produce a version of dart-sass compiled to WASM for distribution (compatible with NodeJS 21+): https://dart.dev/web/wasm

[nex3]

I don't know that we can realistically ship this until April 2026 when Node.js 20 leaves LTS, since we're required by our compatibility policy to continue supporting LTS Node.js releases and npm isn't smart enough to install different packages for different SDK versions.

It's also currently an open question whether WASM actually provides any performance benefits, or how feasible it would be to wrap it with a JS API. One possibility is that we replace the embedded host with WASM as a way of reducing cross-process overhead, but that's also contingent on the runtime performance being comparable with a native executable. Another is that we use the embedded host infrastructure for the main Sass release as a way of exposing the JS API with minimal additional wrapping.

[nex3]

I spent some time today doing a bit of preliminary investigation of this. Here are some issues I've identified, in no particular order:

• There's not a good way to load libraries into a WASM context (How should I load JS libraries from within WASM? dart-lang/sdk#55806). The workarounds for this are no worse than we're already doing for JS interop, though.

• We'd have to update essentially all our JS interop to use Dart's new dart:js_interop library. This isn't a bad idea anyway, but it would probably require us to lead an update of the node_interop package which is fairly large.

• Related to the above, we'd need to find new ways of doing any JS sorcery that currently relies on dart:js_util or the js package, even outside a WASM context, at least until WASM incorrectly advertises dart.library.js dart-lang/sdk#55801 is fixed and it's possible to use different conditional loads for JS and WASM environments.

• We can't even really start to measure the performance implications until most or all of the above issues are handled. At the bare minimum, we need to be able to build Dart Sass as WASM and run it with at least basic filesystem I/O working.

• Dart's WASM support is (at present) tightly coupled to JavaScript as a runtime environment. This means a WASM target would not represent a new way for Sass's compilation logic to be re-used across other runtimes, at least in the short term.

• Dart expects its WASM code to be loaded asynchronously, which could pose a problem given that we're likely to continue to want to expose a CommonJS Sass library for the foreseeable future. This could potentially be worked around by editing the JS wrapper generated by Dart.

If anyone is interested in helping with this effort, the best place to put your energy in the short term would be migrating node_interop to use dart:js_interop.