rollup-plugin-rust minor update: v1.1.0 - asynchronous compile/load, call Javascript function on Rust code, some bug fixes

Repository

https://github.com/DrSensor/rollup-plugin-rust

This minor update consists of 2 things, bug fixes and adding features to support async load/compile. Also, JS function now can be called in Rust code.

update	pull request
async compile/load + call JS function from Rust	https://github.com/DrSensor/rollup-plugin-rust/pull/10
fix failed smoke-test in stenciljs while also add additional smoke-test	https://github.com/DrSensor/rollup-plugin-rust/pull/9
additional smoke-test (example using it in nodejs project)	https://github.com/DrSensor/example-node-rust-wasm/tree/smoke-test

---

New Features

Asynchronous load/compile Wasm code

This feature makes it possible to load/compile wasm code asynchronously to avoid blocking code/execution. This mode are suitable if the wasm code we want to load/compile are big (more than >4KB, maybe^[ref]). See README.md##options.export for more info.

_{resolve value of the exported function depend on export option you choose}

However, if the wasm file compiled from Rust code is really really huge, it's better to use WebAssembly.instantiateStreaming to fetch-compile the wasm file. I actually want to add an additional option for compile/load wasm code in streaming fashion (taking inspiration from here, see Using WebAssembly APIs in JavaScript section) but seems I need to wait for WebAssembly.compileStreaming to be implemented in the most major browser first.

Call Javascript function in Rust code

This feature is really handy if we want to implement lifecycle hook in our wasm code (written in Rust). Well, it's WebAssmebly API feature but since I export async function in all async* mode, it's better to make importObject as an argument and pass it when instantiating wasm code.

It's possible to call JS function in WASM in the non-async mode, but I strongly suggest using async mode (or WebAssembly.instantiateStreaming) to avoid undeterministic execution. If you only need to call functions defined inside the wasm code, then it's fine to use non-async mode.

_{call console.log inside wasm instance}

---

Bug Fixes

Fix failed smoke-test for stenciljs (#9)

This bug happens because of CircleCI recently limit the stack size of nodejs runtime (not sure if they do it directly via it's docker image or its just side effect of fine-tunning the server). Limiting the stack-size of nodejs cause this kind of error:

_{error message cause by stack-size is not enough}

Usually, an error like RangeError: Maximum call stack size exceeded cause by calling the recursive function to deep (or indefinite). The solution for this is simply by defining NODE_OPTIONS=--stack-size=1200 in my local machines but CircleCI prohibits setting --stack-size flag (but not --max-old-space-size, security reason probably). I also add additional smoke-test for nodejs (the repo is in here) just for comparison which surprisingly there is no RangeError: Maximum call stack size exceeded error (it build using rollup -c, not stencil build). As the last resort, I move smoke-stencil job to TravisCI xD

_{FYI: python runtime also has this kind of limit called recursionlimit}

Unfornutaley moving it to TravisCI cause another error.

_{kind of error message cause by hitting the memory limit}

Guess I'm lucky for this. The cause for this error is too many strings (generated code) to be cached. The solution is simple, just enable LTO optimization and the wasm code will be much smaller which make fewer strings (generated code) to be cached. (Glad that I try to explore this in form of tutorial before xD)

Fix buffer is imported but could not be resolved (d87c1d3)

In the previous release, we will get this kind of warning (marked in orange bold) when we do not specify buffer as the external dependency in the rollup.config.js file.

_{when build the examples or smoke-tests}

And when I run the unit-tests locally, I will get this warning message:

_{when running unit-tests}

This update will dismiss that warning by specifying buffer as the external dependency automatically when registering this plugin in rollup.config.js. This fix inspired from rollup-plugin-auto-external.

Strange behaviour when bundling using Rollup .generate() function (c941c62)

This is actually a bug in Rollup that I found when adding another test case. The interesting thing is the bundle result are different between CLI and JS API when doing export * from './content.js' with content export default function() {}. It's hard to explain, so probably will create a reproducible repo and submit bug issue to Rollup next week.

---

Parting words: I leave small feature/mode (#11) that purposely not being implemented in this update to see if I can invite and onboard contribution in this way 😋

---

GitHub Account

https://github.com/DrSensor