wasm-bindgen/wasm-pack v0.5.0

☀️ 0.5.0

on GitHub

Website! - ashleygwilliams, pull/246

We have a website now. It has the installer and links to documentation. In the future,
we hope to have calls to action for folks first coming to the site who are looking to
do specific things- these will help them find the docs and tutorials they need to.

This PR also has a complete rework of our documentation.

Check it out here!

🍱 Module Support

• BREAKING: use correct package.json keys for generated JavaScript - ashleygwilliams, issue/309 pull/312

  This is marked as potentially breaking because it changes the package.json keys that
  are generated by the project.

  Previously, we generated a JavaScript file and placed it in the main key, regardless
  of what you were targeting, ES6 and Node.js alike.

  We have received a lot of requests for wasm-pack to generate "isomorphic" packages,
  that contain assets that could work on both Node.js and ES6, and this led to us
  looking more closely at how we are using package.json.

  With this release, we will do the following:

  • --target broswer: By default, we generate JS that is an ES6 module. We used to put
    this in the main field. Now we put it in the module field. We also add
    sideEffects: false so that bundlers that want to tree shake can.

  • --target nodejs: This target doesn't change. We put generated JS that is a
    CommonJS module in the main key.

  • --target no-modules: This is a new target. For this target we generate bare JavaScript.
    This code is put in a browser field.

  You can see the structs that represent each target's expected package.json here.

  Thanks so much to bterlson for his help in sorting this out for us!

🛠️ New Commands

• wasm-pack init is now wasm-pack build - csmoe, issue/188 pull/216

  When this project was first conceived, we imagined it would be simply a way to package
  up generate wasm and js and publish it to npm. Here we are at version 0.5.0 and we
  have become much more- an integrated build tool!

  As a result, the original command init does a lot more than that these days. We've
  renamed the command to better reflect the work it's actually doing. init will still
  work, but is deprecated now, and we will eventually remove it.

• add new command: wasm-pack test - fitzgen, pull/271

  This is an experimental new command that will run your tests in Node.js or a headless
  browser using wasm-pack test. Check out this tutorial
  to learn more!

• add 2FA support to wasm-pack publish - mstallmo, issue/257 pull/282

  We've been wrapping the npm login and npm publish commands as wasm-pack login
  and wasm-pack publish for a while now- but we didn't fully support two factor
  authentication. Now we do! (Be safe out there! 2FA is good for everyone!)

🎏 New Flags

• New target, bare JavaScript: --target no-modules - ashleygwilliams, issue/317 pull/327

  wasm-bindgen offers a no-modules flag that until now, we didn't support. This flag
  produces bare, no modules JavaScript. So if that's your thing, this target is for you!

• --access flag for wasm-pack publish - ashleygwilliams, issue/297 pull/299

  Many of our tutorials use scopes to help prevent folks from attempting to publish
  packages that will lead to npm Registry errors because the package name already exists.

  However, by default, scoped packages are assumed by the npm registry to be private, and
  the ability to publish private packages to the npm registry is a paid feature. Worry not!
  Now you can pass --access public to wasm-pack publish and publish scoped packages
  publicly.

✅ New Checks

• rustc version check - ashleygwilliams, issue/351 pull/353

  Now that we have a new fangled installer, there's a chance that folks might install wasm-pack
  and not have Rust installed. Additionally, now that the features we required from the nightly
  channel of Rust have moved to beta- we don't need to enforce nightly.

  As of this release, we will check that your Rust version is above 1.30.0. You can be on
  either the nightly or beta channel and all of wasm-packs calls to cargo will
  respect that.

  Really hate this? You can pass --mode force to wasm-pack to skip this check. I hope you know
  what you're doing!

• coordinating wasm-bindgen versions and installing from binaries for improved speed - datapup, issue/146 pull/244 pull/324

  This is the true gem of this release. Have you been frustrated by how long wasm-pack takes to
  run? Overusing --mode no-install? This is the release you're looking for.

  Many releases back we realized that folks were struggling to keep the wasm-bindgen library
  that their project used in sync with the wasm-bindgen CLI application which wasm-pack
  runs for you. This became such an issue that we opted to force install wasm-bindgen to ensure
  that every wasm-pack user had the latest version.

  Like many technical solutions, this solved our original problem, but caused a new one. Now, we
  we are forcing a cargo install of wasm-bindgen on every run, and that means downloading
  and compiling wasm-bindgen everytime you want to run wasm-pack. That's unacceptable!

  We're happy to announce that we have a pretty great solution, and several more planned for
  future releases. As of this release, we will read your Cargo.lock to find the version of
  wasm-bindgen you are using in your local project. We will attempt to fetch a binary version
  of wasm-bindgen that matches your local version. We place that binary local to your project,
  and use it when you run wasm-pack build. The next time you run wasm-pack build we'll use
  that binary, instead of fetching a new one. We still fall back to cargo install for
  less common architectures but this is a huge speed improvement. Check out these benchmarks!

  wasm-pack v0.4.2

  $ time wasm-pack init                   # fresh build
  real    1m58.802s
  user    14m49.679s
  sys     0m24.957s
  
  $ time wasm-pack init                   # re-build
  real    0m56.953s
  user    11m12.075s
  sys     0m18.835s
  
  $ time wasm-pack init -m no-install     # re-build with no-install
  real    0m0.091s
  user    0m0.052s
  sys     0m0.042s
  

  wasm-pack v0.5.0

  $ time wasm-pack build                  # fresh build
  real    1m3.350s
  user    3m46.912s
  sys     0m6.057s
  
  $ time wasm-pack build                  # re-build
  real    0m0.230s
  user    0m0.185s
  sys     0m0.047s
  
  $ time wasm-pack build -m no-install    # re-build with no-install
  real    0m0.104s
  user    0m0.066s
  sys     0m0.041s
  

• enforce cargo build with --lib - ashleygwilliams, issue/303 pull/330

  Right now, wasm-pack only works on Rust library projects. But sometimes, if you're
  new to Rust, you might end up having a main.rs in your project, just by mistake.
  Some folks ran into this and realized that it can cause issues!

  As a result, we are enforcing that cargo build only build the library at this time.

  Want to use wasm-pack on a binary application? We're interested in hearing from you!
  Checkout issue/326 and please comment! We want to support binary applicaitons in
  the future and are always happy and curious to hear about how folks use wasm-pack!

Installers and Releases

• Appveyor Windows Pre-Built binaries - alexcrichton, issue/147 pull/301

  We finally got Appveyor to publish pre-built binaries to GitHub releases.
  Aside: I really wish there were an easier way to test and debug this stuff.

• new experimental installer - alexcrichton, pull/307

  Whew, this one is exciting. Up until now, wasm-pack has been distributed using
  cargo install. This is not ideal for several reasons. Updating is confusing,
  and every time it's installed the user has to wait for it to compile- right at the
  moment they just want to hurry up and use it already.

  Say hello to the new wasm-pack installer- we have an executable for Windows
  and a curl script for *nix users. Not pleased with that? File an issue for your
  preferred distribution method and we'll do our best to get it working!

  This is experimental- so please try it out and file issues as you run into things!
  You'll always be able to use cargo install as a backup.

  Checkout the new installer here!

testing fixture strategy improvements - fitzgen, pull/211 pull/323

split testing utils into separate files - csmoe, issue/231 pull/216

update dependencies - ashleygwilliams, issue/319 pull/320

improve readability of warnings about missing optional fields - twilco, pull/296

A little punctuation goes a long way. Error message improvement PRs are the best.

update links in README - alexcrichton, pull/300

We had a real dicey documentation situation for a while. Sorry about that, and thank
you SO MUCH to all the folks who filed PRs to fix it.

fix broken links in book by using relative paths - mstallmo, issue/325 pull/328