Skip to content

CHANGELOG.md

Latest commit

 

History

History
1147 lines (770 loc) · 53.3 KB

CHANGELOG.md

File metadata and controls

1147 lines (770 loc) · 53.3 KB

Changelog

🌅 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 Cargo.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:

      pre-build publish workflow

    • 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 fixed! You can read more on the background of this issue in rust-lang/rust issue/44542.

    • Validate --target argument - csmoe, issue/483 pull/484

      For a few releases now, wasm-pack has supported allowing users to specifying the target module system they'd like their package built for- browser, nodejs, and no-modules. We did not however, validate this input, and so if a user made even a slight mistake, e.g. node, wasm-pack would not catch the error and would build your project using the default, browser. This is of course, surprising, and unpleasant behavior and so now we'll error out with a message containing the supported target names.

    • Fix login - danwilhelm, issue/486 pull/487

    • Eliminate unecessary escaping in build success terminal output - huangjj27, issue/390 pull/396

      Previously, on some systems, a successful wasm-pack build would print a unfortunate looking string:

      | :-) Your wasm pkg is ready to publish at "\\\\?\\C:\\Users\\Ferris\\tmp\\wasm-bug\\pkg".

      We've updated this to make sure the path to your project is well-formed, and most importantly, human-readable.

    • Copy license file(s) to out directory - mstallmo, issue/407 pull/411

      Since wasm-pack was first published, we've copied over your Cargo.toml license definition over to your package.json. However, we overlooked copying the actual LICENSE files over! Now we do!

    • Don't require cdylib crate-type for testing - alexcrichton, pull/442

      wasm-pack was unecssarily checking Cargo.toml for the cdylib crate type during calls to wasm-pack test. The cdylib output isn't necessary for the wasm-pack test stage because wasm-bindgen isn't being run over a wasm file during testing. This check is now removed!

    • Fix wasm-bindgen if lib is renamed via lib.name - alexcrichton, issue/339 pull/435

      In some circumstances, a library author may wish to specify a name in the [package] portion of their Cargo.toml, as well as a different name in the [lib] portion, e.g.:

      [package]
name = "hello-wasm"

[lib]
name = "wasm-lib"

      This would cause the wasm-bindgen build stage of wasm-pack to error out because wasm-pack would attempt to run wasm-bindgen-cli on a path using the [package] name, which wouldn't exist (because it would be using the [lib] name). Now it works- thanks to more usage of cargo_metadata in wasm-pack internals!

    • Print standard error only once for failing commands - fitzgen, issue/422 pull/424

      Previously, wasm-pack may have printed stderr twice in some circumstances. This was both confusing and not a pleasant experience, so now we've ensued that wasm-pack prints stderr exactly once! (It's hard enough to have errors, you don't want wasm-pack rubbing it in, right?)

    • Add no-modules to --target flag's help text - fitzgen, issue/416 pull/417

      This is an interesting one! fitzgen very reasonably filed an issue asking to add wasm-bindgen's --target no-modules feature to wasm-pack. This was confusing as this feature was indeed already implemented, and documented- BUT, notably missing from the wasm-pack --help text. We've fixed that now- and it was an omission so glaring we definitely considered it a bug!

  • 🛠️ Maintenance

    • Replace slog with log - alexcrichton, issue/425 pull/434

      For internal maintenance reasons, as well as several end-user ones, we've migrated away from the slog family of crates, and are now using the log crate plus env_logger. Now, wasm-pack won't create a wasm-pack.log. Additionally, enabling logging will now be done through RUST_LOG=wasm_pack instead of -v flags.

    • Move binary installation to its own crate - drager, issue/384 pull/415

      In wasm-pack 0.5.0, we move away from cargo installing many of the tools that wasm-pack orchestrates. Because we used cargo install, this required an end user to sit through the compilation of each tool, which was a prohibitively long time. We moved, instead, to building, and then installing, binaries of the tools. This sped up build times dramatically!

      This pattern has been very beneficial to wasm-pack and is potentially something that could be beneficial to other projects! As a result, we've refactored it out into a crate and have published it as it's own crate, binary-install.

    • Replace internal Error with failure::Error - alexcrichton, pull/436

      The story of error message handling in wasm-pack has not been the prettiest. We originally were manually implementing errors, adding the failure crate at one point, but not fully updating the entire codebase. With this PR, we are nearly completely handling errors with failure, bringing the code into a much more maintainable and pleasant-to-work-on place.

    • Update mdbook version used by Travis - fitzgen, pull/433

    • Read the Cargo.toml file only once - fitzgen, issue/25 pull/431

      This is a very fun one since it fixes one of the original issues filed by ag_dubs at the very beginning of wasm-pack development. In a rush to implement a POC tool, ag_dubs noted for posterity that the Cargo.toml was being read multiple times (twice), when it did not need to be. Thanks to fitzgen now it's read only once! A minor performance improvement in the scheme of things, but a nice one :)

    • Use name field for Travis CI jobs - fitzgen, pull/432

    • Add a test for build command - huangjj27, pull/408

    • Test paths on Windows - xmclark, issue/380 pull/389

    • Fix typo in test function name for copying the README - mstallmo, pull/412

  • 📖 Documentation

    • Complete template deep dive docs - danwilhelm, issue/345 issue/346 pull/490

      In a rush to publish a release, ag_dubs left some "Coming soon!" comments on most pages of the "Template Deep Dive" docs. These docs help walk new users through the boilerplate that using the wasm-pack template generates for you. Thanks so much to danwilhem for picking this up and doing an excellent job!

    • Minor docs updates - fitzgen, issue/473 pull/485

🌄 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 browser: 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!

  • 🛠️ Maintenance

  • 📖 Documentation

    • 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

✨ 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 :)

⭐ 0.4.1

  • 🤕 Fixes

    • fix files key value for projects build for nodejs target - ashleygwilliams, issue/199 pull/205

      We became aware that the files key in package.json did not include the additional _bg.js file that wasm-bindgen generates for projects being built for the nodejs target. This resulted in the file not being included in the published package and resulted in a Module Not Found error for folks.

      This was a group effort from mciantyre with pull/200 and Brooooooklyn with pull/197. Thank you so much for your diligence and patience while we sorted through it.

  • 🛠️ Maintenance

    • clean up quicli remnants - SoryRawyer, pull/193

      In v0.3.0 we removed the quicli dependency, however there were a few remnants left behind. They are now removed!

  • 📖 Documentation

    • DOCUMENT EVERYTHING!! and deny missing docs for all future development - fitzgen, pull/208

      The wasm-pack team has worked hard on tutorial documentation and keeping the codebase as self-explanatory as possible, but we have been slowly accruing a documentation debt. This amazing PR, landed just moments before this point release and was just too good not to include. Thank you so much, fitzgen!

    • fix README code example - steveklabnik, pull/195

      The code example in our README.md was missing a critical pub. It's there now!

    • fix README markup - Hywan, pull/202

      There was an errant ` - it's gone now!

🌟 0.4.0

This release has a ton of awesome things in it, but the best thing is that almost all of this awesome work is brought to you by a new contributor to wasm-pack. Welcome ya'll! We're so glad to have you!

✨ Features

  • 🎏 New Flags

    • --mode flag for skipping steps when calling init - ashleygwilliams, pull/186

      After teaching and working with wasm-pack for some time, it's clear that people would like the flexibility to run some of the steps included in the init command and not others. This release introduces a --mode flag that you can pass to init. The two modes currently available are skip-build and no-installs and they are explained below. In the future, we are looking to change the init interface, and potentially to split it into two commands. If you have thoughts or opinions on this, please weigh in on issue/188!

      • skip-build mode - kohensu, pull/151

        wasm-pack init --mode skip-build

        Sometimes you want to run some of the shorter meta-data steps that wasm-pack init does for you without all the longer build steps. Now you can! Additionally, this PR was a fantastic refactor that allows even more custom build configurations will be simple to implement!

      • no-installs mode - ashleygwilliams, pull/186

        wasm-pack init --mode no-installs

        Sometimes you want to run wasm-pack and not have it modify your global env by installing stuff! Or maybe you are just in a hurry and trust your env is set up correctly- now the --mode no-install option allows you to do this.

    • --debug - clanehin, pull/127

      wasm-pack init --debug

      Find yourself needing to compile your Rust in development mode? You can now pass the --debug flag to do so! Thanks so much to clanehin for filing issue/126 for this feature... and then implementing it!

  • ✅ New Checks

    • ensure you have cdylib crate type - kendromelon, pull/150

      One of the biggest mistakes we've seen beginners make is forgetting to declare the cdylib crate type in their Cargo.toml before running wasm-pack init. This PR fixes that, and comes from someone who ran into this exact issue learning about wasm-pack at JSConfEU! Love when it works out like this.

    • ensure you have declared wasm-bindgen as a dep - robertohuertasm, pull/162

      Another easy mistake to make is to forget to declare wasm-bindgen as a dependency in your Cargo.toml. Now wasm-pack will check and make sure you have it set before doing a bunch of long build steps :)

    • ensure you are running nightly - FreeMasen, pull/172

      wasm-pack currently requires that you run it with nightly Rust. Now, wasm-pack will make sure you have nightly installed and will ensure that cargo build is run with nightly. Thanks so much to FreeMasen for filing issue/171 and fixing it!

🤕 Fixes

  • fixed broken progress bar spinner - migerh, pull/164

    Oh no! We broke the progress bar spinner in version 0.3.0. Thankfully, it's fixed now- with a thoughtful refactor that also makes the underlying code sounder overall.

🛠️ Maintenance

  • WIP bot - ashleygwilliams & mgattozzi, issue/170

    We've got a lot of work happening on wasm-pack so it's good to have a bit of protection from accidentally merging a Work In Progress. As a result, we now have the WIP Github App set up on wasm-pack. Great suggestion mgattozzi!

  • modularize command.rs - ashleygwilliams, pull/182

    Thanks to the growth of wasm-pack, command.rs was getting pretty long. We've broken it out into per command modules now, to help make it easier to read and maintain!

  • improve PoisonError conversion - migerh, pull/187

    As part of the awesome progress bar spinner fix in pull/164, migerh introduced a small concern with an unwrap due to an outstanding need to convert PoisonError into wasm-pack's custom Error. Though not a critical concern, migerh mitigated this right away by replacing std::sync::RwLock with the parking_lot crate! This cleaned up the code even more than the previous patch!

  • wasm category for crates.io discovery- TomasHubelbauer, pull/149

    crates.io has categories to help folks discover crates, be we weren't leveraging it! Now- if you explore the wasm category on crates.io you'll see wasm-pack!

📖 Documentation

  • cleaned up the README - ashleygwilliams, pull/155

    Our README was struggling with a common problem- doing too much at once. More specifically, it wasn't clear who the audience was, contributers or end users? We've cleaned up our README and created a document specifically to help contributors get up and running.

🌠 0.3.1

Babby's first point release! Are we a real project now?

🤕 Fixes

  • fixed init Is a Directory error - ashleygwilliams, pull/139

    Our new logging feature accidentally introduced a regression into 0.3.0. When calling wasm-pack init, if a directory was not passed, a user would receive a "Is a Directory" Error. Sorry about that! Thanks to jbolila for filing issue/136!

  • typescript files were not included in published package - danreeves, pull/138

    Generating Typescript type files by default was a pretty rad feature in 0.3.0 but we accidentally forgot to ensure they were included in the published package. Thanks so much to danreeves for catching this issue and fixing it for us!

💫 0.3.0

✨ Features

  • Logging - mgattozzi, pull/134

    Up until now, we've forced folks to rely on emoji-jammed console output to debug errors. While emojis are fun, this is often not the most pleasant experience. Now we'll generate a wasm-pack.log file if wasm-pack errors on you, and you can customize the log verbosity using the (previously unimplemented) verbosity flag.

  • --target flag - djfarly, pull/132

    wasm-bindgen-cli is able to generate a JS module wrapper for generated wasm files for both ES6 modules and CommonJS. Up until now, we only used wasm-bindgen's default behavior, ES6 modules. You can now pass a --target flag with either nodejs or browser to generate the type of module you want to use. Defaults to browser if not passed.

  • human readable panics - yoshuawuyts, pull/118

    Panics aren't always the most friendly situation ever. While we never want to panic on ya, if we do- we'll do it in a way that's a little more readable now.

  • typescript support by default - kwonoj, pull/109

    wasm-bindgen now generates typescript type files by default. To suppress generating the type file you can pass the --no-typescript flag. The type file is useful for more than just typescript folks- many IDEs use it for completion!

  • wrap npm login command - djfarly, pull/100

    In order to publish a package to npm, you need to be logged in. You can now use wasm-pack login to login to the npm (or any other) registry.

  • exit early on failure - mgattozzi, pull/90

    Until now, wasm-pack would continue to run tasks, even if a task failed. Now- if something fails, we'll exit so you don't have to wait to fix the error.

🤕 Fixes

  • force install wasm-bindgen - ashleygwilliams, pull/133

    Using an out of date version of wasm-bindgen can run you into a bunch of trouble. This very small change should fix the large number of bug reports we received from users using an out of date wasm-bindgen-cli by force installing wasm-bindgen-cli to ensure the user always has the latest version. We don't expect this to be a forever solution (it's a bit slow!) but it should help those who are getting started have a less rough time.

  • fix CI release builds - ashleygwilliams, pull/135

    This was not working! But now it is! You can always use cargo install to install wasm-pack, but now you can find pre-built Linux and Mac binaries in the Releases tab of our GitHub repo.

🛠️ Maintenance

  • remove quicli dependency - mgattozzi, pull/131

    While quicli is a great way to get started writing a CLI app in Rust- it's not meant for large, mature applications. Now that wasm-pack is bigger and has many active users, we've removed this dependency to unblock further development on the tool.

  • update rustfmt CI test - djfarly, pull/128

    Since 0.2.0 how one should call rustfmt changed! We've kept it up to date so we can continue to maintain conventional style in the codebase.

  • custom module for errors - mgattozzi, pull/120

    Thanks to the failure crate, we've been playing fast and loose with errors for a bit. We're finally getting serious about error handling - by organizing all of our specific errors in a specific module. This will make it easier to communicate these errors out and handle new error cases from future features.

📖 Documentation

Special thanks to data-pup who continues to be our documentation champion! In case you missed it, check out the guides in the docs directory!!

🌌 0.2.0

This release focuses on filling out all commands and improving stderr/out handling for improved user experience!

✨ Features

  • pack and publish - jamiebuilds, pull/67 You can now run wasm-pack pack to generate a tarball of your generated package, as well as run wasm-pack publish to publish your package to the npm registry. Both commands require that you have npm installed, and the publish command requires that you be logged in to the npm client. We're working on wrapping the npm login command so that you can also login directly from wasm-pack, see pull/100 for more details.

  • package.json is pretty printed now - yoshuawuyts, pull/70

    Previously, package.json was not very human readable. Now it is pretty printed!

  • collaborators - yoshuawuyts, pull/70

    wasm-pack now will fill out the collaborators field in your package.json for you based on your Cargo.toml authors data. For more discussion on how we decided on this v.s. other types of author fields in package.json, see issues/2.

🤕 Fixes

🛠️ Maintenance and 📖 Documentation

Thanks so much to mgattozzi, data-pup, sendilkumarn, Andy-Bell, steveklabnik, jasondavies, and edsrzf for all the awesome refactoring, documentation, typo-fixing, and testing work. We appreciate it so much!

💥 0.1.0

  • First release!