This approach works great for NodeJS, but once I ran a test bundle I found that Webpack (and bundlephobia) included all the base64 “release” variants instead of lazy-loading the import statements. Bummer. I assumed this because Typescript on its own compiled import to Promise.resolve(require(…)), so it’s good to know that most bundlers will STILL get this wrong even if I’m emitting ES6 module import syntax. Yikes! I need to bite the bullet and start using Rollup to emit a slew of separate entry points. Oy veh.
Anyways A+++ would read again. This will save me 4-5 days of work stubbing my toe on bundlers and build system which is the Least Fun part of JS work.
You don't want to be in a position to ship code to production with binary code that could potentially be harmful
Off topic: Please don't mess up the way my browser scroll pages, it is infuriating
That said I generally agree with the premise, and even with sandboxing you should vet dependencies like these where appropriate if you can. A good example of this is something like an image decoder versus a database library (both of these being real scenarios; e.g. using a pure-Rust implementation of some SQL protocol.) The first one I probably wouldn't worry too about much, you're just giving it pixels in and getting pixels out. But the second one is likely worth a bit of scrutiny since it interfaces directly with a sensitive component.
For instance if you create a web mail application the code probably has access to all mails, can delete them, can send mail under the user's identity, ...
How relevant those scenarios are you have to evaluate.
If you compile yourself, you can verify the source to increase trust. If you just get the binary, you have to trust the vendor more.
pyodide.loadPackage("numpy");
pyodide.loadPackage("https://foo/bar/numpy.js");
# import micropip
micropip.install('https://example.com/files/snowballstemmer-2.0.0-py2.py3-none-any.whl')
conda-forge: "WASM as a supported architecture" https://github.com/conda-forge/conda-forge.github.io/issues/...