🌦️ 0.10.0

• ✨ Features

  • Added keywords - lucashorward, issue/707 pull/838

    package.json files usually contain a keywords array so that npm can make searching easier.
    This PR extracts keywords from Cargo.toml and puts them into package.json.

• 🤕 Fixes

  • Update binary-install to get fix for axios security vulnerability - simlay, Rizary, issue/958 pull/973 pull/1012

    Updates binary-install npm package to version ^0.1.0 in order to get security fix for a security vulnerability in axios.

  • Fix cargo-generate installation - bradyjoslin, issue/975 issue/907 pull/983

    wasm-pack new hello-wasm didn't work due to a bad link when trying to install cargo-generate.

    This PR points the installation to the correct place and makes wasm-pack new working again!

  • Pass through extra options when building tests - azriel91, issue/698 pull/851

    wasm-pack test accepts extra options to pass through to cargo when running tests.
    Under the hood, this runs cargo build before cargo test, and the additional options were only passed through to the test command. This meant that crates that enabled native features by default could not be built using wasm-pack, as it would attempt to build tests for the wasm32-unknown-unknown target with the native features enabled.

    This PR passes through the extra options to cargo when building the tests as well.

  • Corrected files included in package.json for bundler / no target - lucashorward, issue/837 pull/839

    wasm-pack build and wasm-pack build --target bundler generates a _bg.js file, but it was not added to the package.json.
    The file that is added, *.js will however reference the _bg.js, so when the package was distributed (both through pack or publish) it is not usable.

    This PR includes that _bg.js file in package.json.

  • Find the main package if multiple packages have the same name - ghost, pull/830

    If there were 2 packages with the same name, wasm-pack would sometimes use the wrong one and errored.

• 📖 Documentation

  • Remove duplicated "is" in the wee_alloc tutorial- pione30, issue/1003 pull/1004

  • Fix TOC links - Swaagie, pull/1007

  • Remove outdated TOC heading- gthb, pull/1011

  • Add link to template repo - milahu, pull/942

  • Remove greenkeeper reference - cdvv7788, crotwell, issue/1001 pull/844 pull/1002

• 🛠️ Maintenance

  • Fix CI. Remove appveyor and travis and use Github actions - ashleygwilliams, drager, issue/594 issue/979 pull/947

  • Cargo update - ashleygwilliams, pull/800

  • Remove dirs dependency - brightly-salty, issue/943 pull/944

  • Fix logs for uniformity - petosorus, issue/716 pull/723

  • Fixing build error - Pauan, pull/841

☁️ 0.9.1

• 🤕 Fixes

  • Bump binaryen to version_90 - ashleygwilliams, issue/781 issue/782 pull/687

    Previously, wasm-pack was hardcoded to install and attempt to execute wasm-opt on every build
    using binaryen version 78. This version had various issues on Unix/Linux and caused broken CI
    builds for many folks (we're so sorry!).

    This PR updates the binaryen version to 90, which should fix the issues folks were having.

    Long-term, we'd like to create an auto-updating mechanism so that we can install and use the
    latest release of binaryen as we do for other binaries we orchestrate.

• 🛠️ Maintenance

  • Consolidate wasm-opt installation into existing binary install logic - ashleygwilliams, issue/685 pull/687

🌥️ 0.9.0

• ✨ Features

  • Adding in --quiet and --log-level flags to control the console output - Pauan, pull/694

    The --verbose flag has long existed as a way to get more console output, but now there are two flags to get less console output:

    • --quiet will silence all stdout, so only errors will be displayed.
    • --log-level can be used to silence [INFO] or [WARN] output from wasm-pack.

    You can cause it to display even more information by using --verbose, or you can silence all stdout by using --quiet.

    You can also use --log-level to have fine-grained control over wasm-pack's log output:

    • --log-level info is the default, it causes all messages to be logged.
    • --log-level warn causes warnings and errors to be displayed, but not info.
    • --log-level error causes only errors to be displayed.

    These flags are global flags, so they can be used with every command, and they must come before the command:

    wasm-pack --log-level error build
    wasm-pack --quiet build

  • Wrap cargo-generate with wasm-pack new - ashleygwilliams, issue/373 pull/623

    One of the first steps in getting started with wasm-pack is to cargo install cargo-generate to bootstrap some project templates. This can take a while and is an extra burden on users just getting started with wasm-pack. wasm-pack new uses cargo-generate to bootstrap new projects, removing the need to install the tool on your own. You can read more about this feature here.

  • Allow wasm-pack to be run from subdirectories - gameldar, issue/620 pull/624

    If a crate path is not specified when running wasm-pack and there is no Cargo.toml in the current working directory, wasm-pack will walk up the directory structure to find a Cargo.toml.

  • Automatically execute wasm-opt on produced binaries - alexcrichton, issue/159 pull/625

    When wasm-pack builds binaries in released and profiling modes, it will execute wasm-opt on the binary, making the result smaller and more performant.

  • Helpful error message when wasm-bindgen fails because of an old version - gameldar, ashleygwilliams, issue/627 pull/633

    wasm-pack will pass a --web flag to wasm-bindgen when wasm-pack build --target web is run. Before, if the user had an old version of wasm-bindgen in their dependencies, they would receive a cryptic error message. Now they will be notified that they need to update their wasm-bindgen dependency if they want to build for the web target.

  • Publish releases by tag to npm - Tarnadas, pull/690

    You can now use wasm-pack publish to publish tagged releases with the optional --tag argument. You can read more about distribution tags on NPM, and more about this feature in our docs.

• 🤕 Fixes

  • Only use exactly v0.24.0 geckodriver on Windows - ashleygwilliams, issue/770 pull/774

    wasm-pack test is a great way to test your web Wasm modules- and it very nicely sets up and configures
    the necessary browser engine drivers to do so!

    For the v0.25.0 release of geckodriver, the team switched their build environment- which introduced a new
    surprise runtime dependency, Visual C++ redistributable package, to their windows binaries. You can read
    more about the issue here, mozilla/geckodriver/issue/1617.

    Becuase the introduction of this runtime dependency is considered a bug, and should be eventually fixed,
    the team decided that the least invasive solution would be to hold geckodriver binaries, on Windows, at
    v0.24.0, and to disable the auto-update logic, until the bug is fixed.

  • Handle version check failures - drager, issue/652, issue/653 pull/660

    Every day, wasm-pack checks the crates.io API for the latest version number and lets the user know if their installation is out of date. Now, when these API calls fail, wasm-pack alerts the user of the failure and waits until the next day to make another call to crates.io.

  • Add user agent for version check - drager, issue/651 pull/658

    crates.io requires tools to set a version check User-Agent header when requesting the latest version. Now, when wasm-pack performs an API request to crates.io, it sends User-Agent: wasm-pack/0.9.0.

  • Remove broken link from the README - drager, pull/635

  • Make sideEffects in generated package.json a boolean instead of a string - rhysd, pull/649

  • Don't warn if license-file is present - ashleygwilliams, issue/692 pull/693

    Previously, wasm-pack would warn that the license field was missing if the license-file field was used instead. This warning is now only surfaced if both license and license-field are absent from a Cargo.toml.

  • Select correct webdriver version - MartinKavik, issue/611 pull/706

    wasm-pack used to install a pinned version of the Chrome, Gecko, and Safari drivers. Now when a driver needs to be installed, wasm-pack will pull the latest version from the API and install that instead.

  • Only run node tests on wasm-pack test --node - alexcrichton, pull/630

  • Fix npm installs for Windows Users - EverlastingBugstopper, issue/757 pull/759

    We recently published wasm-pack on the npm registry but forgot to test on Windows! npm install -g wasm-pack now works on Windows machines.

  • Clean up cargo test warnings - ashleygwilliams, issue/752 pull/753

    Tests now use std::sync::Once::new() instead of the deprecated std::sync::ONCE_INIT

• 📖 Documentation

  • Document npm installer - drager, issue/751 pull/767

  • Update help message for build and publish subcommands - ibaryshnikov, issue/636 pull/640

    wasm-bindgen recently changed the default target from browser to bundler and deprecated browser. This change is now reflected in the help message for wasm-pack build.

  • Add Release Checklist - ashleygwilliams, [issue/370] pull/626

    While we try to automate releases of wasm-pack as much as possible, there are still some manual steps that need to be completed when releasing a new version (like writing a changelog 😉). These steps now live in RELEASE_CHECKLIST.md.

🛠️ 0.8.1

• 🤕 Fixes

  • Check for "rustup" rather than ".rustup" when checking for wasm32 - drager, issue/613

    When we introduced support for non-rustup setups we did a check if the user was
    using rustup or not. However, this check was too constrained and only covered
    the most common cases, but it did not work for Docker setups.

    This PR addresses that and it now covers Docker setups as well!
    When doing this fix we also found two other small issues which this PR also addresses.
    The first is that we did not print the helpful error message when the wasm32 target
    was not found and the other one was that it linked to the wrong section of the documentation.

🌤️ 0.8.0

• ✨ Features

  • Give user's ability to customize generated filenames with --out-name flag - ibaryshnikov, issue/596 pull/599

    When running wasm-pack build, several files are generated. These files are named based on the name of the crate, as per your Cargo.toml file. Sometimes- that's not the name you'd like your files to have!

    You can now specify a custom name for the generated files using a new flag, --out-name. Given a project called dom, here's a comparison of the default and custom generated filenames:

    wasm-pack build
    # will produce files
    # dom.d.ts  dom.js  dom_bg.d.ts  dom_bg.wasm  package.json  README.md
    
     wasm-pack build --out-name index
    # will produce files
    # index.d.ts  index.js  index_bg.d.ts  index_bg.wasm  package.json  README.md
    

• 🤕 Fixes

  • Fix panics in build mode --no-install - alexcrichton, pull/598

    This commit fixes the wasm-pack build --mode no-install command from unconditionally panicking as well as --mode force. These steps were calling an unwrap() on an internal Option<T> which was supposed to be set during step_install_wasm_bindgen, but that step wasn't run in these modes. The mode configuration of steps has been refactored slightly to ensure that more steps are shared between these modes to reduce duplication.

  • Print unexpected panics to standard error - drager, issue/562 pull/601

    Unexpected panics are unfortunate but they're currently covered up and written out to an auxiliary file. This makes panics in CI difficult to debug, especially at a glance, as CI builders are likely not uploading those files.

    This PR will print to standard error for unexpected panics and then let human_panic handle panics, just like before.

  • Improve error message when wasm32-unknown-unknown is missing - drager, issue/579 pull/602

    For folks with non-rustup environments (which we only started supporting in 0.7.0!), we were giving a missing target error that was not helpful!

    We've updated the error message to include more information, and we've added some documentation to help explain how you can remedy the error by manually installing the target on your specific rust setup- including the fact that it may not be possible to add the target to some setups.

    Check out the docs here.

• 📖 Documentation

  • Document --out-dir flag - ashleygwilliams, issue/592 pull/593

    Recently, someone asked on Discord about customizing the name of the directory that contains the assets built by wasm-pack. We've had the out-dir flag for a while, but it wasn't documented! Now it is.

  • Fix broken links in docs and update for template changes - drager, ashleygwilliams, issue/609 pull/612 pull/614

    Recently, some improvements were made to the wasm-pack-template. Additionally, there were some broken links in the documentation. We've updated the docs for the new template and fixed the broken links!

• 🛠️ Maintenance

  • Move binary-install to its own repo - drager, issue/500 pull/600

    binary-install is a crate that holds the abstractions for how wasm-pack downloads and caches pre-built binaries for the tools it wraps. It was originally part of the wasm-pack code, then moved into a workspace as an independent crate. Now that we believe it's stable, we've moved it into its own repo!

🌤️ 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!

🌅 0.6.0

• ✨ Features

  • Add three build profiles and infrastructure for their toml config - fitzgen, issue/153 issue/160 pull/440

    When originally conceived, wasm-pack was exclusively a packaging and publishing tool, which naively assumed that the crate author would simply run wasm-pack when they were ready to publish a wasm package. As a result, wasm-pack always ran cargo build in --release mode. Since then, wasm-pack has grown into an integrated build tool used at all stages of development, from idea conception to publishing, and as such has developed new needs.

    In previous releases, we've supported a flag called --debug which will run cargo build in dev mode, which trades faster compilation speed for a lack of optimizations. We've renamed this flag to --dev to match cargo and added an additional flag, representing a third, intermediary, build profile, called --profiling which is useful for investigating performance issues. You can see all three flags and their uses in the table below:

    Profile	Debug Assertions	Debug Info	Optimizations	Notes
    --dev	Yes	Yes	No	Useful for development and debugging.
    --profiling	No	Yes	Yes	Useful when profiling and investigating performance issues.
    --release	No	No	Yes	Useful for shipping to production.

    The meaning of these flags will evolve as the platform grows, and always be tied to the behavior of these flags in cargo. You can learn more about these in the cargo profile documentation.

    This PR also introduces a way to configure wasm-pack in your Cargo.toml file that we intend to use much more in the future. As a largely convention-based tool, wasm-pack will never require that you configure it manually, however, as our community and their projects mature alongside the tool, it became clear that allowing folks the ability to drop down and configure things was something we needed to do to meet their needs.

    Currently, you can only configure things related to the above-mentioned build profiles. To learn more, check out the documentation. It leverages the package.metadata.wasm-pack key in your Cagol.toml, and looks like this:

    # Cargo.toml
    
    [package.metadata.wasm-pack.profile.dev.wasm-bindgen]
    # Should we enable wasm-bindgen's debug assertions in its generated JS glue?
    debug-js-glue = true
    # Should wasm-bindgen demangle the symbols in the "name" custom section?
    demangle-name-section = true
    # Should we emit the DWARF debug info custom sections?
    dwarf-debug-info = false

    As always- there are defaults for you to use, but if you love to configure (or have a project that requires it), get excited, as your options have grown now and will continue to!

  • DEPRECATION: Rename --debug to --dev to match cargo - fitzgen, pull/439

    See the discussion of the build profiles feature above. This is a strict renaming of the previous --debug flag, which will now warn as deprecated.

  • Add an option to pass an arbitrary set of arguments to cargo build - torkve, issue/455 pull/461

    As an integrated build tool, wasm-pack orchestrates many secondary command line tools to build your package in a single command. Notably, one of these tools is cargo. cargo has a wide array of features and flags, and we couldn't reasonably expect to implement them all as first class features of wasm-pack. As a result, we've created the option to allow users to pass an arbitrary number of additional flags to wasm-pack by appending them to the wasm-pack build command, after passing --. For example:

    wasm-pack build examples/js-hello-world --mode no-install -- -Z offline
    

    In the above example, the flag -Z offline will be passed to cargo build. This feature is documented here.

  • Pre-build before wasm-pack publish - csmoe, issue/438 pull/444

    Previously, if you ran wasm-pack publish before you had successfully run wasm-pack build,
    you'd receive an error that a package could not be found- because there would be no pkg or
    out-directory containing a package.json.

    In this situation, you would hope that wasm-pack would build your package for you when you
    ran wasm-pack publish. This is slightly complicated by the fact that not everyone wants to
    build their package to the default target or to a directory named pkg.

    To solve this, running wasm-pack publish before a successful build will give you an interactive
    prompt to build your package- allowing you to specify your out directory as well as the target you'd
    like to build to. Check it out in the gif below:

    

  • Generate self-.gitignore as part of pkg folder - RReverser, pull/453

    Since wasm-pack was first published, the pkg directory was intended to be treated as a build artifact, and as such should never be published to version control. This was never enforced by any assets generated by wasm-pack, however.

    Now, when building your package, wasm-pack will also generate a .gitignore file so that the pkg, or out-directory, will be ignored.

    If you use another version control tool, you'll need to still create or edit your own ignore file- pull requests to support other version control tools are welcome!

    If you require editing of the generated package.json or add additonal assets to your package before publishing, you'll want to remove the .gitignore file and commit to version control. We intend to have a solution that makes this workflow significantly easier in upcoming releases!

  • Support cargo workspaces - fitzgen, issue/252 issue/305 pull/430

    Workspaces are a well-liked and used feature of cargo that allow you to build multiple crates in a single cargo project. Because of how wasm-pack handled paths for target and out-directories, we did not support cargo workspaces out of the box. Now they should work well and the feature is well guarded by tests!

  • Use a global cache for all downloaded binaries - alexcrichton, pull/426

    wasm-pack is an integrated build tool that orchestrates several other command line tools to build your wasm project for you. How wasm-pack does this has evolved significantly since it's early versions. In the last version, a bin directory was created to house the tool binaries that wasm-pack needed to build our project, but this had several limitations. Firstly, it created a bin directory in your project's root, which could be confusing. Secondly, it meant that sharing these tools across multiple projects was not possible. We did this because it gaves us the fine-grained control over the version of these tools that you used.

    Now, wasm-pack will not generate a bin directory, but rather will use a global cache. We retain the fine-grained control over the versions of these tools that are used, but allow multiple projects that use the same tools at the same versions to share the already installed asset. Your global cache will generally be in your user's home directory- we use the dirs crate to determine where to place this global cache. This is not currently customizable but is something we intend to look into doing!

    This feature ensures that wasm-pack users are downloading a minimal number of binaries from the network, which, for wasm-pack users with multiple projects, should speed up build times.

• 🤕 Fixes

  • Fix pack, login, and publish for Windows users - [danwilhelm], [issue/277] [pull/489]

    Rust's behavior for spawning processes on some Windows targets introduced an interesting case where Rust would fail unless the command was explicitly spawned with a prepended cmd /c. This failure of wasm-pack was well noticed by our community - and thanks to the efforts of danwilhelm is now fix...

🌄 0.5.1

• 🤕 Fixes

  • Child Process and output management - fitzgen, issue/287 pull/392

    Not exactly a "fix", but definitely a huge improvment in how child processes and their
    output are handled by wasm-pack. Ever sat at a long prompt from wasm-pack and
    wondered what was happening? No longer! Did wasm-pack eat your test output- no more!

  • Less scary missing field messages - mstallmo, issue/393 pull/394

    After watching a livestream of someone using wasm-pack, fitzgen noted that folks
    seemed pretty alarmed by the loud warning about missing optional manifest fields.
    As a result, we are now downgrading those messages from WARN to INFO, and consolidating
    them on a single line.

  • Add exit_status to CLI errors - konstin, issue/291 pull/387

    We'd been hiding these- but we shouldn't have been!

  • Remove lingering forced nightly usage - alexcrichton, pull/383

    In 0.5.0 we removed all forced nightly usage as we depend on ~1.30 which is now
    available on both nightly and beta channels! We had a bit of a race condition with
    that PR and the wasm-pack test PR, and missed a few as a result! This removes all
    lingering forced nightly, which only affected the wasm-pack test command.

  • Fix wasm-bindgen-test dependency error message - fitzgen, issue/377 pull/378

    The error message about missing the wasm-bindgen-test dependency errantly stated
    that the user was missing a wasm-bindgen dependency! We've fixed it to correctly
    state the missing dependency now.

  • Fix prerequisites links in docs - fitzgen, pull/376

• 🛠️ Maintenance

  • Leverage failure::Error consistently - drager, issue/280 pull/401

    This PR finally makes it so that wasm-pack is handling errors in a consistent
    way across the codebase.

☀️ 0.5.0

• ✨ Features

  • 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], [...

✨ 0.4.2

• 🤕 Fixes

  • recognize [dependencies.wasm-bindgen] during dep check in init - ashleygwilliams, issue/221 pull/224

    When we originally implemented the dependency check in wasm-pack init we naively only checked for the "simple" dependency declaration, [dependencies] wasm-bindgen="0.2". However! This is not the only way to declare this dependency, and it's not the ideal way to do it if you want to specify features from the crate. Now that a bunch of folks want to use features = ["serde-serialize"] we ran into a bunch of folks having issues with our naive dependency checker! Thanks so much to turboladen for filing the very detailed issue that helped us solve this quickly!

    PSSSST! Curious what features = ["serde-serialize"] with wasm-bindgen actually does? It's awesome:

    It's possible to pass data from Rust to JS not explicitly supported in the Feature Reference by serializing via Serde.

    Read the Passing arbitrary data to JS docs to learn more!

  • improve UX of publish and pack commands - Mackiovello, pull/198

    Previous to this fix, you would need to be in the parent directory of the /pkg dir to successfully run pack or publish. This was pretty crummy! Thankfully, Mackiovello swooped in with a fix, that you can find documented in the pack and publish docs!

  • use PathBuf instead of String for paths - Mackiovello, pull/220

    This is mostly a maintenance PR but does fix one very small bug- depending on if you add a trailing slash to a path that you pass to init, you might have seen an extra /! Now that we're using a proper Type to handle this, that's much better, and in general, all the operations using paths are more robust now.

• 📖 Documentation

  • update docs and tests to eliminate no longer necessary feature flags - ashleygwilliams, pull/226

    The Rust 2018 edition marches on and we are seeing feature flags drop like flies :) Instead of a whole slew of feature flags, we now only need one, #![feature(use_extern_macros)], and that one is also not long for this world :)