🌤️ 0.7.0

• ✨ Features

  • Non rustup environment support - drager, pull/552

    Before now, wasm-pack had a hard requirement that rustup had to be in the PATH. While most Rust users userustup there are variety reasons to have an environment that doesn't use rustup. With this PR, we'll now support folks who are using a non-rustup environment!

  • Improved CLI Output - alexcrichton, pull/547

    It's hard to decide if this is a fix or a feature, but let's keep it positive! This PR moves wasm-pack's CLI output strategy closer to the desired standard we have for 1.0. This is important as it fixes many small bugs that are distributed across a diveristy of terminals and difficult to test for locally.

    This strategy was first introduced as a mini RFC in issue/298, and then was discussed in a session at the Rust All Hands (notes).

    You'll notice that the spinner is gone- we eventually want to have one, but we'd like one that doesn't cause bugs! If you have feedback about terminal support or an output bug, please file an issue! We want to hear from you!

    Check out the new output in the README demo- or update your wasm-pack and take it for a spin!

  • Add support for --target web - alexcrichton, pull/567

    Recently, wasm-bindgen add a new target- web. This new target is similar to the no-modules target, in that it is designed to generate code that should be loaded directly in a browser, without the need of a bundler. As opposed to the no-modules target, which produces an IIFE (Immediately Invoked Function Expression), this target produces code that is an ES6 module.

    You can use this target by running:

    wasm-pack build --target web
    

    Learn more about how to use this target by checking out the docs!

  • Support passing arbitrary arguments to cargo test via wasm-pack test - chinedufn, issue/525 pull/530

    wasm-pack test is an awesome command that wraps cargo test in a way that helps provide you some nice out of the box configuration and setup. However, you may find yourself wanting to leverage the full funcationality of cargo test by passing arguments that haven't been re-exported by the wasm-pack test interface.

    For example, if you have a large test suite, it can be nice to simply run one test, or a subset of your tests. cargo test supports this, however up until now, the wasm-pack test interface did not!

    wasm-pack test now accepts passing and arbitrary set of arguments that it will forward along to its cargo test call by allowing users to use -- after any wasm-pack test arguments, followed by the set of arguments you'd like to pass to cargo test.

    For example:

    # Anything after `--` gets passed to the `cargo test`
    wasm-pack test --firefox --headless -- --package my-workspace-crate my_test_name --color=always
    

    This will just run the my_test_name test and will output using color!

    See the test docs here!

  • Support homepage field of Cargo.toml and package.json - rhysd, pull/531

    Both Cargo.toml and package.json support a homepage field that allow you to specify a website for your project. We didn't support it previously (purely an accidental omission) - but now we do!

  • Support license-file field in Cargo.toml - rhysd, pull/527

    Sometimes, you want to provide a custom license, or specific license file that doesn't map to SPDX standard licenses. In Rust/Cargo, you accomplish this by omitting the license field and including a license-file field instead. You can read more about this in the cargo manifest documentation.

    In an npm package, this translates to "license": "SEE LICENSE IN <filename>" in your package.json. You can read more about this in the npm package.json documentation.

    We previously only supported using SPDX standard licenses, by only supporting the "license" key in your Cargo.toml- but now we'll allow you to leverage the license-file key as well, and will translate it correctly into your package.json!

• 🤕 Fixes

  • wasm-pack-init (1).exe should work - ashleygwilliams, issue/518 pull/550

    Several users noted that when downloading a new version of wasm-pack their browser named the executable file wasm-pack-init (1).exe. When named this way, the file didn't show the init instructions on execution. This happened because the installation logic was requiring an exact match on filename. We've loosened that restriction so that the filename must start with wasm-pack-init and will still execute files with these additional, extraneous characters in the filename. Thanks so much to Mblkolo and [danwilhelm] for filing the issue and the excellent discussion!

  • Fix chromedriver error and message on Windows for wasm-pack test - jscheffner, issue/535 pull/537

    When running wasm-pack test on a 64-bit Windows machine, users would receive an error:geckodriver binaries are unavailable for this target. This error message had two issues- firstly, it accidentally said "geckodriver" instead of "chromedriver", secondly, it threw an error instead of using the available 32-bit chromedriver distribution. Chromedriver does not do a specific disribution for Windows 64-bit!

    We've fixed the error message and have also ensured that 64-bit Windows users won't encounter an error, and will appropriately fallback to the 32-bit Windows chromedriver.

  • Correct look up location for wasm-bindgen when it's installed via cargo install - fitzgen, pull/504

    Sometimes, when a wasm-bindgen binary is not available, or if wasm-pack is being run on an architecture that wasm-bindgen doesn't produce binaries for, instead of downloading a pre-built binary, wasm-pack will install wasm-bindgen using cargo install. This is a great and flexible back up!

    However, due to the last release's recent refactor to use a global cache, we overlooked the cargo install case and did not look for wasm-bindgen in the appropriate location. As a result, this led to a bug where wasm-pack would panic.

    We've fixed the lookup for the cargo install'd wasm-bindgen by moving the cargo-install'd version to global cache location for wasm-pack once it's successfully built. We also eliminated the panic in favor of propagating an error. Thanks for your bug reports and sorry about the mistake!

  • Only print cargo test output the once - fitzgen, issue/511 pull/521

    Due to some technical debt and churn in the part of the codebase that handles output, we were accidentally printing the output of cargo test twice. Now we ensure that we print it only one time!

• 🛠️ Maintenance

  • Fix clippy warnings - [mstallmo], issue/477 pull/478

    clippy is an awesome utilty that helps lint your Rust code for common optimizations and idioms. at the beginning of wasm-pack development, clippy had not yet stablized, but it has since 1.0'd and it was high time we leveraged it in wasm-pack. We still aren't completely fixed, but we're working on it, and we've already dervived a ton of value from the tool!

  • Run clippy check on Travis - drager, pull/502

    Now that wasm-pack has been clippified- we want to keep it that way! Now in addition to cargo fmt and cargo test, we'll also run cargo clippy on all incoming PRs!

  • Port tests to use assert-cmd - fitzgen, pull/522

    assert_cmd is a great utility for testing CLI applications that is supported by the CLI WG. wasm-pack development began before this library existed- so we were using a much less pleasant and efficient strategy to test the CLI functionality of wasm-pack. Now we've ported over to using this great library!

  • Add initial tests for binary-install crate - drager, pull/517

    In the last release, we separated some of our binary install logic into a new crate, binary-install. However, that's about all we did... move the logic! In an effort to move the crate into true open source status, drager has done some excellent work adding tests to the crate. This was trickier than it looked and involved creating a test server! Thanks for all the efforts drager, and the great review work fitzgen and lfairy!

  • Update tests wasm-bindgen version - huangjj27, issue/519 issue/417 pull/526

    Our tests use fixtures that reference wasm-bindgen often, but the versions were not consistent or up to date. As a result, the test suite leverage many version of wasm-bindgen which meant that they took a while to run as they couldn't use the cached version of wasm-bindgen because the cached versions we slightly different! Now they are up to date and consistent so the tests can perform better!

• 📖 Documentation

  • Flag gh-pages docs as unpublished - alexcrichton pull/565

    Recently, DebugSteven made a PR to merge all the documentation for the rustwasm toolchain into a single location. This is going to make discovering and using tools from the entire organization easier for new and seasoned folks alike. This also has the feature of displaying documentation that is related to the current published version of each tool- unlike before, where the only accessible documentation was for the tools at current master (which may or may not be currently published!)

    If you like reading the current master's documentation- fear not, each tool will still publish the documentation generated from the master branch on their individual gh-pages (See wasm-pack's master docs here). To avoid confusion, we've added a flash message that let's you know which documentation you are reading- and provides a link to documentation of the published version- just in case that's what you're looking for!

  • Add new QuickStart guide for "Hybrid Applications with Webpack" - DebugSteven pull/536

    Since wasm-pack was first published, we've focused on a workflow where a user writes a library and then publishes it to npm, where anyone can use it like any npm package in their JavaScript or Node.js application.

    Shortly after wasm-pack appeared, some RustWASM teammates created a template for a similar workflow- building a RustWASM package alongside an application. They did this by leveraging Webpack plugins, and it's a really lovely user experience!

    [This template] hasn't gotten as much attention because we've lacked a quickstart guide for folks to discover and follow- now we've got one!

    Check out the guide here!

  • Add wee_alloc deepdive - surma, pull/542

    wee_alloc is a useful utility that deserved more attention and explanation than our previous docs addressed. This was partially because the wasm-pack template has an explanatory comment that helps explain its use. However, for folks who don't use the template, wee_alloc is something important to know about- so now we have given it its own section!

    Check out the deepdive here!

  • Update prerequisite documentation - alexcrichton, pull/569

    Many folks are using wasm-pack without publishing to npm- as a result, we've updated the documentation to clearly indicate that npm is an optional requirement, only required for specific targets and workflows. Additionally, since the 2018 Edition landed, nightly Rust is no longer a requirement. We've removed those instructions and have consolidated the documentation so it is shorter and more efficient at getting you started!

  • Clarify what kind of account login adds - killercup, pull/539

    Previously, when view --help, the command description for login showed: 👤 Add a registry user account! This could be confusing for folks, so now it's been updated to read: 👤 Add an npm registry user account!, which is much clearer!

  • Wasm is a contraction, not an acronym - fitzgen, pull/555

    Ever wonder how you're actually supposed to refer to WebAssembly in short-form? WASM? wasm? For the pedants out there, the correct usage is "Wasm" because Wasm is a contraction of the words Web and Assembly. We've updated our documentation to consistently refer to WebAssembly as Wasm in the shortform.

    The more you know!

  • Fix links and Rust highlightning - drager, issue/513 pull/514 pull/516

    We had some broken links and missing Rust syntax highlighting in a few sections of the docs. This fixes that!