Move "helper functions" in JS to an NPM package

[alexcrichton]

Right now all the helper functions are generated inline in the JS that wasm-bindgen generates, but this can be a problem if you have multiple wasm-bindgen-generated wasm files throughout your dependency graph in a larger JS application. Each wasm-bindgen-generated project would duplicate the shims (that probably look the same) and so there's not as much code sharing happening, bummer!

It'd be pretty slick if all the helper functions were located on npm already in a package that wasm-bindgen generates imports to. That way all the wasm-bindgen-generated projects would import the same glue and it'd make everything smaller.

I think if this were implemented the JS file that we generate is basically then just the bare minimum to wrap the wasm imports/exports of the Rust/C code, and it'd make it a bit smaller!

[alexcrichton]

cc @xtuc

[alexcrichton]

This also is likely to have ramifications on #42 and #18, generating #[wasm_bindgen] annotations from WebIDL and Typescript. The JS shims for imported functions are gonna look the same regardless of what project you're working in and regardless of what language you're working in, so ideally if two projects import console.log then they're both wired up to the same JS shim.

[sendilkumarn]

Awesome. I think I can take this one 😊

[alexcrichton]

Ok! One tricky part I think is how this interacts with the no modules mode and how the wasm-bindgen output is not as usable by default, and I'm not sure how to best tackle those issues

[xtuc]

Also it has some other advantages:

• Tree shakeable
• Upgradeable (since just a regular dep)
• The glue itself is easier to maintain; it can be a separated project distributed over npm

Note that this would only work with Rollup and Webpack (currently).

---

I mentioned during the meeting that it could make sense to compile Rust's libstd or libc to wasm and just include IO from JS. Since the bundlers consideres wasm just like JS module the approach here will still be applicable (but not tree-shakeable currently (i'm also working on it)).

This solution avoids porting the libs to JavaScript, which I believe has many limitations (pthread? i64?).

[valpackett]

Related to this: would be great to have a --modules-but-not-wasm-as-modules mode :) that would

• generate all the project-specific glue (__exports.my_cool_function) in an ES Module
• but without trying to import '*.wasm'
  • instead, just have the function init(wasm_path) from the no-module mode in the module
• and the module should import common glue from the published common module suggested above, of course

[alexcrichton]

I'm gonna close this for now because the shim functions are still in so much churn I'm not sure if it's feasible to extract them to a helper package at this time. Additionally I think it'll be quite some time before this causes bloat in applications, so we can hopefully cross the bridge when we get there!