Since it's been past 1 month, I need to update this 2 packages 😄
Because this 2 packages now depend on webassembly-loader, most of the features in webassembly-loader are now rs-jest and rollup-plugin-rust features. Most of the features can be follow up in the CHANGELOG.md of that loader which are NOT marked as a library.
😞 Problems and Workaround
Starting from why there is a small adjustment in webassembly-loader, some packages that was suggested by official Webpack documentation can't be tree-shaked by Rollup.
Those library (schema-utils & loader-utils) can't be tree-shaked when used in a project that use Rollup which make rs-jest and rollup-plugin-rust bloated. The only solution I can think of is to separate bundle results of webassembly-loader between when used as a webpack loader and used as a library[code] which make webassembly-loader behave differently when the bundler/transpiler do es6 import because those bundler/transpiler usually respect
module field rather than
In rollup-plugin-rust, I use webassembly-loader with option
esm [code] which generate ECMAScript export (
export default ...) because I can't ever imagine rollup-plugin-rust to be used in a project that doesn't respect pkg.module or es6 import. Actually Rollup itself only care es6 module and disregard any module convention, including CommonJS.
While in rs-jest, I use webassembly-loader with option
esm [code] which generate CommonJS export (
module.exports = ...) because Jest only support CommonJS module, not the others like es6 module. Also, I don't register custom error handler like in rollup-plugin-rust [code] because Jest doesn't have that.
Thanks to dependabot (which I set to check the dependencies every month), I notice that the smoke-test behave strangely because I forgot to remove the lockfile in examples repository. Before this fix/refactor, I use git submodule to manage/separate the smoke-test.
However, on this fix, I remove those git submodule and change it to normal project folder. The reason I use git submodule before is to avoid resetup/prepare the smoke-test on each project that use it. Now I change my mind because I need to track the changes on each project when the smoke-test fail again.
I also took this chance to see if CircleCI jobs smoke-test for stenciljs is fail again [ref]. After this fix seems it's not causing
RangeError: Maximum call stack size exceeded again in CircleCI (maybe they fix that) so I bring back the smoke-test for stenciljs from Travis to CircleCI. I just disable the CI in Travis and not remove travis.yml config in case CircleCI limit the nodejs stack-size again.
Before fix After fix
Ah yes, while at it 👇
First of, the reason why I lock the testing to use 1.28.0 not later is because webassembly-loader will try to throw an Error when wasm code is over 4KB when using export mode
module at compile time see [commit-msg]. Because Rust v1.28.0 not yet support macros
#[wasm_import_module], I need to update the test suites [code]
🍐 Weird stuff (a058cb9)
Since Jest only care about main field [#module][#browser], I need to use this resolver script to make Jest respect pkg.module first. To make that script works, I need to make Jest ignore modules that support pkg.module [code]. Excluding webassembly-loader, I found out only rollup and estree that support pkg.module. Even though I have renamed
babel.config.js to make it also lookup on node_modules folder, seems like babel-jest will not pick it up if the path doesn't get listed in
- Need to investigate the output result of wasm-pack to know if it produce smaller bundle size. It's a bit downer that latest stable Rust targeting
wasm32-unknown-unknownproduce wasm with the most minimum size 57KB :sad:
- Integrate with wasmsnip, wasmopt, etc.
- Investigate if wasm-pack can replace neon.
What I learn when updating this 2 packages
- There is a trick in wasm-pack-plugin to install wasm-pack if it's not yet installed [ref]. Seems I can use that in the future update.
- There is an ongoing PR for supporting Webassembly in Rollup [ref] :yay:. Hopefully it can tree-shake WebAssembly exports function. Seems I can begin to support code-splitting or dynamic import for wasm when it's merged. Less headache for me because I don't need to support exporting as WebAssembly.instantiateStreaming 😂
- There is a stalled PR to make Jest support for the "module" package.json field [ref].
- Babel configuration file have different behaviour depend on how you name the file (e.g
You may notice that I never mentioned about wasm-bindgen. My other purpose creating this 2 packages is to streamline the web and embedded development, so I will avoid wasm-bindgen when creating a project that use this 2 packages. However, PR for integrating wasm-bindgen is always welcome 🤗.