๐Ÿ“ฆโœจ your favorite rust -> wasm workflow tool!


๐Ÿ“ฆ โœจ wasm-pack

Your favorite Rust โ†’ Wasm workflow tool!

Build Status Build status crates.io

Docs | Contributing | Chat

Built with ๐Ÿฆ€ ๐Ÿ•ธ by The Rust and WebAssembly Working Group


This tool seeks to be a one-stop shop for building and working with rust- generated WebAssembly that you would like to interop with JavaScript, in the browser or with Node.js. wasm-pack helps you build rust-generated WebAssembly packages that you could publish to the npm registry, or otherwise use alongside any javascript packages in workflows that you already use, such as webpack.

This project is a part of the rust-wasm group. You can find more info by visiting that repo!


๐Ÿ”ฎ Prerequisities

This project requires Rust 1.30.0 or later.

โšก Quickstart Guide

Visit the quickstart guide in our documentation.

๐ŸŽ™๏ธ Commands

  • new: Generate a new RustWasm project using a template
  • build: Generate an npm wasm pkg from a rustwasm crate
  • test: Run browser tests
  • pack and publish: Create a tarball of your rustwasm pkg and/or publish to a registry

๐Ÿ“ Logging

wasm-pack uses env_logger to produce logs when wasm-pack runs.

To configure your log level, use the RUST_LOG environment variable. For example:

RUST_LOG=info wasm-pack build

๐Ÿ‘ฏ Contributing

Read our guide on getting up and running for developing wasm-pack, and check out our contribution policy.

๐Ÿคนโ€โ™€๏ธ Governance

This project is part of the rustwasm Working Group.

This project was started by ashleygwilliams and is co-maintained by ashleygwilliams, drager and the Rust Wasm Working Group Core Team.

  • Security alert for axios 0.19.0 (npm dependency)

    Security alert for axios 0.19.0 (npm dependency)

    ๐Ÿ› Bug description

    There is a security alert for axios 0.19.0, which is in npm/package-lock.json.

    ๐Ÿค” Expected Behavior

    It should be upgraded to 0.21.1. (Upgrading binary-install to 0.1.0 and then running npm update should fix it.)

    ๐Ÿ‘Ÿ Steps to reproduce

    Any package that uses wasm-pack has this warning: image

    ๐ŸŒ Your environment

    Include the relevant details of your environment. wasm-pack version: 0.9.1

    opened by btzy 39
  • wasm-opt: Exported global cannot be mutable

    wasm-opt: Exported global cannot be mutable

    ๐Ÿ› Bug description

    I am using wasm-pack and wasm-bingen to build a javascript package with rust.

    Since today when I am running wasm-pack build I am getting following error:

    [INFO]: Checking for the Wasm target...
    [INFO]: Compiling to Wasm...
        Finished release [optimized + debuginfo] target(s) in 13.59s
    [INFO]: Installing wasm-bindgen...
    [INFO]: Optimizing wasm binaries with `wasm-opt`...
    [wasm-validator error in module] unexpected true: Exported global cannot be mutable, on 
    # --- omitted .wast output ---
    Fatal: error in validating input
    Error: failed to execute `wasm-opt`: exited with exit code: 1
      full command: "~/.cache/.wasm-pack/wasm-opt-4d7a65327e9363b7/wasm-opt" "$REPO/rav1e_js/pkg/rav1e_js_bg.wasm" "-o" "$REPO/rav1e_js/pkg/rav1e_js_bg.wasm-opt.wasm" "-O"
    To disable `wasm-opt`, add `wasm-opt = false` to your package metadata in your `Cargo.toml`.

    It was still working on master yesterday (see CI), but doesn't anymore today with the same commit (see CI). (The important step is "Build").

    ๐Ÿค” Expected Behavior

    Build package and optimize it with wasm-opt as it did before.

    (Running wasm-pack build --dev works, but I'd like to have the optimization).

    ๐Ÿ‘Ÿ Steps to reproduce

    Trying a few things I figured out that I can make wasm-opt pass when I am removing all exported (non-static) methods on the exported structs (which is abviously not desireable).

    On urhengulas/rav1e@wasm-opt-fix I removed all the methods and it builds and optimizes fine:

    โžœ  rav1e git:(wasm-opt-fix) โœ— cd rav1e_js && wasm-pack build
    [INFO]: Checking for the Wasm target...
    [INFO]: Compiling to Wasm...
        Finished release [optimized + debuginfo] target(s) in 0.05s
    [INFO]: License key is set in Cargo.toml but no LICENSE file(s) were found; Please add the LICENSE file(s) to your project directory
    [INFO]: Installing wasm-bindgen...
    [INFO]: Optimizing wasm binaries with `wasm-opt`...
    [INFO]: :-) Done in 0.88s
    [INFO]: :-) Your wasm pkg is ready to publish at /home/urhengulas/Documents/github.com/xiph/rav1e/rav1e_js/pkg.

    But, as soon I am adding a method (e.g. fn Frame.debug(&self) -> Self in rav1e_js/src/frame.rs) back, I am getting the error from the bug description.

    ๐ŸŒ Your environment

    Include the relevant details of your environment.

    โžœ  rustc --version
    rustc 1.45.0 (5c1f21c3b 2020-07-13)
    โžœ  wasm-pack --version
    wasm-pack 0.9.1
    โžœ  ~/.cache/.wasm-pack/wasm-opt-4d7a65327e9363b7/wasm-opt --version
    wasm-opt version_90


    Thanks to everyone taking the time and having a look at this issue!

    opened by Urhengulas 32
  • should we generate typscript type files by default?

    should we generate typscript type files by default?

    a question came up in solving issue #107 on PR #109: should we generate typescript type files by default?

    i have requested that the PR land behind a flag but i'm curious to hear the arguments for why it should be default! this is the issue for that convo :)

    opened by ashleygwilliams 31
  • bugfix(command/build.rs): Cancel Escape

    bugfix(command/build.rs): Cancel Escape

    fix #390

    Make sure these boxes are checked! ๐Ÿ“ฆโœ…

    • [x] You have the latest version of rustfmt installed and have your cloned directory set to nightly
    $ rustup override set nightly
    $ rustup component add rustfmt-preview --toolchain nightly
    • [x] You ran rustfmt on the code base before submitting
    • [x] You reference which issue is being closed in the PR text

    โœจโœจ ๐Ÿ˜„ Thanks so much for contributing to wasm-pack! ๐Ÿ˜„ โœจโœจ

    changelog - fix 
    opened by huangjj27 29
  • fix canonical paths windows

    fix canonical paths windows

    This PR addresses problems with canonical paths on windows that were reported in #380. I tested this by building a wasm app with a few dependencies on windows.

    I would love somebody to check the work and try running it on another windows box targeting another wasm app ๐Ÿ˜„ .

    Implementation: Remove the usage of std::fs::canonicalize.

    Unit test: I added a unit test based on reported failures:

    • a project with local transitive dependencies, see #413
    changelog - maintenance 
    opened by xmclark 29
  • Strange behavior on first run of `wasm-pack init`

    Strange behavior on first run of `wasm-pack init`

    ๐Ÿ› Bug description

    So in a new Rust project, I have my code written and sitting pretty and everything works. I am then ready to compile to wasm. I run wasm-pack init and get an error (described below). If I run the same command again, everything works as expected. ๐Ÿค” So weird.


    $ wasm-pack init --scope tejaskumar
      [1/8] ๐Ÿ”ง  Checking crate configuration...
      [2/8] ๐ŸŽฏ  Adding WASM target...
      [3/8] ๐ŸŒ€  Compiling to WASM...
      [4/8] ๐Ÿ“‚  Creating a pkg directory...
      [5/8] ๐Ÿ“  Writing a package.json...
      โš ๏ธ   [WARN]: Field description is missing from Cargo.toml. It is not necessary, but recommended
      โš ๏ธ   [WARN]: Field repository is missing from Cargo.toml. It is not necessary, but recommended
      โš ๏ธ   [WARN]: Field license is missing from Cargo.toml. It is not necessary, but recommended
      [6/8] ๐Ÿ‘ฏ  Copying over your README...
      โš ๏ธ   [WARN]: origin crate has no README
      [7/8] โฌ‡๏ธ  Installing WASM-bindgen...
    | [8/8] ๐Ÿƒโ€โ™€๏ธ  Running WASM-bindgen...
    wasm-bindgen failed to execute properly. stderr:
    error: failed to read `target/wasm32-unknown-unknown/release/my_wasmp.wasm`
    	caused by: No such file or directory (os error 2)

    ๐Ÿค” Expected Behavior

    What should have happened? It should have created a pkg folder with my npm package ready to go.

    ๐Ÿ‘Ÿ Steps to reproduce

    Clear steps describing how to reproduce the issue, including commands and flags run. If you are seeing an error, please include the full error message and stack trace.

    Unfortunately, this is completely random and hard to reproduce. :(

    ๐ŸŒ Your environment

    Include the relevant details of your environment. wasm-pack version: 0.4.2 rustc version: rustc 1.28.0 (9634041f0 2018-07-30)

    bug PR attached user report 
    opened by TejasQ 28
  • Coordinating with wasm-bingden about versions and list of NPM dependencies

    Coordinating with wasm-bingden about versions and list of NPM dependencies

    This is related to https://github.com/rust-lang-nursery/rust-wasm/issues/34 and https://github.com/rust-lang-nursery/rust-wasm/issues/36, but I'd like to propose a strawman idea here.

    Right now wasm-bindgen has the ability to say where you're importing functionality from:

    #[wasm_bindgen(module = "foo")]
    extern {
        // ...

    If module = "..." is omitted it's assumed to come from the ambient environment (aka the browser). Otherwise foo is interpreted as an ES module directive and that's where items are imported from in the generated JS that wasm-bindgen emits.

    The wasm-bindgen output is pretty "dumb" right now in that it's just bland ES module information, it doesn't currently attempt to give extra information like verison requirements for NPM packages. But that's where wasm-pack comes in! Ideally wasm-bindgen would emit information that wasm-pack later reads, parses, and emits a package.json for.

    So I'd propose something like:

    • Add support for version = "..." next to module = "..." in wasm-bindgen
    • For all module = "..." directives that don't start with ., require that version is listed
    • Emit a new section in the wasm executable in the wasm that wasm-bindgen emits in the format:
      • The section name is __wasm_pack_unstable
      • The section format is a list of elements. Each element is prefixed with 4 bytes of how long it is and then the rest of the data is a JSON payload.
      • The JSON payload for each element is currently { "module": "string", "version": "string" }
    • When wasm-pack executes it slurps up the __wasm_pack_unstable section, if present, and emits these packages into the package.json that's generated.

    An example of using this would look like:

    #[wasm_bindgen(module = "moment", version = "2.0.0")]
    extern {
        type Moment;
        fn moment() -> Moment;
        fn format(this: &Moment) -> String;
    pub fn run() -> String {

    And wasm-pack would automatically generate a package.json with:

       "dependencies": {
            "moment": "2.0.0"

    I'm definitely up for changing anything here, this is just an initial strawman! I'd love to hear others' thoughts on this as well.

    question to-do PR attached 
    opened by alexcrichton 28
  • reading the cargo toml 2x is kinda gross

    reading the cargo toml 2x is kinda gross

    This issue is reserved for someone who has not yet contributed to this codebase.

    Currently we read the Cargo.toml twice! this is not preferred:

    1. read it to write package.json
    2. read it to pass crate name to wasm-bindgen

    MENTORING INSTRUCTIONS (from @mgattozzi !):

    1. Create a small expression or function to read the Cargo.toml file to a String and assign it to a variable, maybe something like CARGO_TOML
    2. Replace instances of it being read with the variable you just created
    3. Remove any code associated with reading the file
    changelog - maintenance 
    opened by ashleygwilliams 28
  • no prebuilt wasm-opt binaries error

    no prebuilt wasm-opt binaries error

    ๐Ÿ› Bug description

    I'm running wasm-pack on a raspberry pie 3b (arm v71). and are trying the game of life tutorial. Build 'fails' with an error. (I say 'fails', as I get something that works after all.)

    ~/rust/wasm-game-of-life $ wasm-pack build [INFO]: Checking for the Wasm target... [INFO]: Compiling to Wasm... Finished release [optimized] target(s) in 0.50s [INFO]: Installing wasm-bindgen... Error: no prebuilt wasm-opt binaries are available for this platform: Unrecognized target! To disablewasm-opt, addwasm-opt = falseto your package metadata in your 'Cargo.toml'.

    ๐Ÿค” Expected Behavior

    Looking at wasm-opt.rs, I would have expected the build to successfully complete, giving the message "Skipping wasm-opt because it is not supported on this platform". It also doesn't seem to look for a local wasm-opt in the path, as described above pub fn find_wasm_opt. I downloaded the wasm-opt source, build it locally and added the bin dir it to the path... source doesn't show any signs of looking at the path...

    ๐Ÿ‘Ÿ Steps to reproduce

    Get a raspberry pie, install raspbian OS, install git, rust, wasm, etc git clone https://github.com/rustwasm/wasm_game_of_life.git cd wasm_game_of_life/ wasm_pack build

    ๐ŸŒ Your environment

    Include the relevant details of your environment. wasm-pack version: 0.9.1 rustc version: 1.46.0

    bug wasm-opt 
    opened by JHBonarius 23
  • wasm-pack can't install wasm32-unknown-unkonwn target on DragonFly BSD

    wasm-pack can't install wasm32-unknown-unkonwn target on DragonFly BSD

    ๐Ÿ› Bug description

    Following the hello world tutorial example, I seem to hit 32bit requirements on a 64bit only operating system.

    The following was observed, and annotated in another issue here:

    I tried building off commit badbe1c, as well as off the 0.6.0 tag and the 0.7.0 tag, all failed. This was as well with the hello world example.

    In order: 0.6.0, 0.7.0, master

    zach@dev03 ~/wasm-pack-template> wasm-pack build
      [1/10] Checking `rustc` version...
      [2/10] Checking crate configuration...
    | [3/10] Adding WASM target...
    Error: Adding the wasm32-unknown-unknown target with rustup
    Caused by: No such file or directory (os error 2)
    zach@dev03 ~/wasm-pack-template> ../wasm-pack/target/release/wasm-pack build
    [INFO]: Checking for the Wasm target...
    Error: wasm32-unknown-unknown target not found!
    zach@dev03 ~/wasm-pack-template> ../wasm-pack/target/release/wasm-pack build
    [INFO]: Checking for the Wasm target...
    Error: wasm32-unknown-unknown target not found!

    ๐Ÿค” Expected Behavior

    I expected that the hello world example would work out of the box, but it's possible that the documentation is not explicit that only 32bit compilation is supported and/or that 32bit libraries are required and/or that rustup support is required with 32bit binaries and libraries for this.

    ๐Ÿ‘Ÿ Steps to reproduce

    I did a git clone of the wasm-pack-template (my version of cargo does not support generate), so I then edited the Cargo.toml for an arbitrary author name and project name.

    I installed the latest release of wasm-pack by cargo (0.6.0 as of this morning) and tried to do wasm-pack build, after not working and finding an issue exhibiting what I thought was the issue, checked out the source and did a git checkout of 0.7.0, with the a similar error. I then checked out master and tried on master with the same error as on 0.7.0.

    ๐ŸŒ Your environment

    Include the relevant details of your environment. wasm-pack version: 0.6.0,0.7.0, master (badbe1c37a752963243da526b6fb01b66e7889bd) rustc version: 1.31.1

    user report 
    opened by strangelittlemonkey 21
  • Error for missing wasm32-unknown-unknown on non-rustup environments can be improved

    Error for missing wasm32-unknown-unknown on non-rustup environments can be improved

    ๐Ÿ› Bug description

    As a newbie I am following the tutorial at https://rustwasm.github.io/book/game-of-life/hello-world.html and get errors

    ๐Ÿค” Expected Behavior

    When building the project with wasm-pack build I expect no errors.

    ๐Ÿ‘Ÿ Steps to reproduce

    $ cargo generate --git https://github.com/rustwasm/wasm-pack-template

    then type wasm-game-of-life

    $ cd wasm-game-of-life
    $ wasm-pack build
    [INFO]: ๐ŸŽฏ  Checking for the Wasm target...
    Error: wasm32-unknown-unknown target not found!

    ๐ŸŒ Your environment

    Include the relevant details of your environment. wasm-pack version: 0.7.0 rustc version: 1.31.0 MacOS Sierra

    bug PR attached user report 
    opened by gotcha 20
  • MacOS Ventura - wasm-pack v0.10.3 fails to build

    MacOS Ventura - wasm-pack v0.10.3 fails to build

    ๐Ÿ› Bug description

    wasm-pack v0.10.3 fails to install on MacOS Ventura (Intel)

    ๐Ÿค” Expected Behavior

    It should be possible to compile.

    ๐Ÿ‘Ÿ Steps to reproduce

    1. git clone [email protected]:xtuc/svg-to-png-worker.git - the repository is at https://github.com/xtuc/svg-to-png-worker
    2. npx wrangler build

    That yields the following for me:

    error[E0277]: the trait bound `proc_macro2::Span: From<proc_macro::Span>` is not satisfied
       --> /Users/juhovepsalainen/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro-error-1.0.4/src/lib.rs:549:24
    549 |                 first: self.clone().into(),
        |                        ^^^^^^^^^^^^ ---- required by a bound introduced by this call
        |                        |
        |                        the trait `From<proc_macro::Span>` is not implemented for `proc_macro2::Span`
        = note: required for `proc_macro::Span` to implement `Into<proc_macro2::Span>`
    error[E0277]: the trait bound `proc_macro2::Span: From<proc_macro::Span>` is not satisfied
       --> /Users/juhovepsalainen/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro-error-1.0.4/src/lib.rs:550:23
    550 |                 last: self.clone().into(),
        |                       ^^^^^^^^^^^^ ---- required by a bound introduced by this call
        |                       |
        |                       the trait `From<proc_macro::Span>` is not implemented for `proc_macro2::Span`
        = note: required for `proc_macro::Span` to implement `Into<proc_macro2::Span>`

    I was able to reproduce the issue separately using the rust template of https://github.com/cloudflare/templates that's available through npm init cloudflare my-project worker-rust.

    I could also reproduce the issue directly against this repository by cloning it first and then running cargo install.

    ๐ŸŒ Your environment

    Include the relevant details of your environment. wasm-pack version: 0.10.3 rustc version: 1.66.0 (69f9c33d7 2022-12-12) (built from a source tarball)

    opened by bebraw 0
  • Can't import the named export (imported as 'wasm')

    Can't import the named export (imported as 'wasm')

    Hi! I used wasm-pack build command and I'm getting the following error:

    ERROR in ./src/wasm-lib/pkg/index_bg.js 15:14-29

    wasm-pack-plugin: Can't import the named export (imported as 'wasm') from default-exporting module (only default export is available)

    The ./src/wasm-lib/pkg/index_bg.js file is auto-generated and looks like this:

    import * as wasm from './wasm_lib_bg.wasm';
    * @param {number} left
    * @param {number} right
    * @returns {number}
    export function sort_array(left, right) {
        const ret = wasm.sort_array(left, right);
        return ret >>> 0;

    I also added the syncWebAssembly flag to my Webpack config.

    opened by bart-krakowski 0
  • wasm-pack build segfaults

    wasm-pack build segfaults

    ๐Ÿ› Bug description

    Running wasm-pack build in https://github.com/Boddlnagg/midir/tree/master/examples/browser gives a segmentation fault.

    ๐Ÿค” Expected Behavior

    It should have built a pack.

    ๐Ÿ‘Ÿ Steps to reproduce

    $ git clone https://github.com/Boddlnagg/midir/
    $ cd midir/examples/browser
    $ wasm-pack build               
    zsh: segmentation fault  wasm-pack build

    A stack trace from GDB (RUST_BACKTRACE=1 didnโ€™t print anything):

    #0  0x0000555555855494 in OPENSSL_sk_value ()
    #1  0x000055555585c8ca in X509_STORE_add_lookup ()
    #2  0x00007ffff76d580b in X509_STORE_load_file_ex (ctx=0x7ffff0010b30, file=file@entry=0x7ffff00095f0 "/etc/ssl/certs/ca-certificates.crt", libctx=0x555555e545c0 <TLS_client_method_data.14>, propq=0x0) at ../crypto/x509/x509_d2.c:51
    #3  0x00007ffff7ab6e63 in SSL_CTX_load_verify_file (ctx=<optimized out>, CAfile=CAfile@entry=0x7ffff00095f0 "/etc/ssl/certs/ca-certificates.crt") at ../ssl/ssl_lib.c:4425
    #4  0x00007ffff7f52ea0 in ossl_connect_step1 (data=data@entry=0x7ffff0001f20, conn=conn@entry=0x7ffff0008df0, sockindex=sockindex@entry=0) at vtls/openssl.c:3362
    #5  0x00007ffff7f55817 in ossl_connect_common (data=0x7ffff0001f20, conn=0x7ffff0008df0, sockindex=0, nonblocking=true, done=0x7ffff6c8b3b3) at vtls/openssl.c:4059
    #6  0x00007ffff7f56868 in Curl_ssl_connect_nonblocking (data=data@entry=0x7ffff0001f20, conn=conn@entry=0x7ffff0008df0, isproxy=isproxy@entry=false, sockindex=sockindex@entry=0, done=done@entry=0x7ffff6c8b3b3) at vtls/vtls.c:371
    #7  0x00007ffff7f0d256 in https_connecting (done=0x7ffff6c8b3b3, data=0x7ffff0001f20) at ./debian/build/lib/http.c:1650
    #8  Curl_http_connect (data=0x7ffff0001f20, done=0x7ffff6c8b3b3) at ./debian/build/lib/http.c:1576
    #9  0x00007ffff7f2661c in protocol_connect (protocol_done=0x7ffff6c8b3b3, data=0x7ffff0001f20) at ./debian/build/lib/multi.c:1773
    #10 multi_runsingle (multi=multi@entry=0x7ffff00011e0, nowp=nowp@entry=0x7ffff6c8b430, data=data@entry=0x7ffff0001f20) at ./debian/build/lib/multi.c:2089
    #11 0x00007ffff7f27536 in curl_multi_perform (multi=multi@entry=0x7ffff00011e0, running_handles=running_handles@entry=0x7ffff6c8b538) at ./debian/build/lib/multi.c:2682
    #12 0x00007ffff7efd94b in easy_transfer (multi=<optimized out>) at ./debian/build/lib/easy.c:663
    #13 easy_perform (events=false, data=0x7ffff0001f20) at ./debian/build/lib/easy.c:753
    #14 curl_easy_perform (data=0x7ffff0001f20) at ./debian/build/lib/easy.c:772
    #15 0x00005555556df7a4 in wasm_pack::manifest::Crate::return_api_call_result ()
    #16 0x00005555556df3b5 in wasm_pack::manifest::Crate::return_wasm_pack_latest_version ()
    #17 0x0000555555685ddd in wasm_pack::build::check_wasm_pack_versions ()
    #18 0x000055555565c605 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
    #19 0x00005555556641c9 in core::ops::function::FnOnce::call_once{{vtable.shim}} ()
    #20 0x0000555555b882a3 in alloc::boxed::{impl#44}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:1940
    #21 alloc::boxed::{impl#44}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:1940
    #22 std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:108
    #23 0x00007ffff7d85fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #24 0x00007ffff7e0666c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

    ๐ŸŒ Your environment

    Include the relevant details of your environment. wasm-pack version: 0.10.3 (installed via cargo) rustc version: 1.65.0 (897e37553 2022-11-02)

    opened by yath 6
  • Windows support

    Windows support

    ๐Ÿ’ก Feature description

    Full Windows support.

    ๐Ÿ’ป Basic example

    Considering significantly higher popularity of Windows OS among developers, me (and not only me) wondering why you're forcing Linux system as a must-use?


    Please add normal Windows support (via cargo, without need to download a separate file). A lot of people will be grateful to you.

    opened by f1am3d 0
  • Error during the execution of `wasm-pack build --target web` command

    Error during the execution of `wasm-pack build --target web` command

    ๐Ÿ› Bug description

    Many weird errors after running command wasm-pack build --target web wasm-pack-error.log

    ๐Ÿค” Expected Behavior

    No errors, obviously.

    ๐Ÿ‘Ÿ Steps to reproduce

    Follow these steps: https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm#rust_and_webassembly_use_cases

    ...and on the step "building the package" you will get this error

    ๐ŸŒ Your environment

    wasm-pack version: latest ( 0.10.3 ) rustc version: latest ( 1.66.0 (69f9c33d7 2022-12-12) )

    opened by f1am3d 1
  • Getting JSON results back from wasm-pack test

    Getting JSON results back from wasm-pack test

    ๐Ÿ’ก Feature description

    Hi, in regular Rust, we can use something like cargo test -- -Z unstable-options --format json to get the test results back in JSON format.

    I tried wasm-pack test --firefox --headless -- -Z unstable-options --format json but it's not the right syntax. Is it possible for the current version of wasm-pack test to return the test results in JSON format?

    Thank you very much.

    opened by ziontee113 0
  • v0.10.3(Jun 13, 2022)

    • ๐Ÿค• Fixes

      • Use bash to create release tarballs - [nasso], [issue/1097] pull/1144

        Fixes Windows installer failure due to malformatted tar.

        [issue/1097]: https://github.com/rustwasm/wasm-pack/issues/1097 [nasso]: https://github.com/nasso

      • Clean up package.json from previous runs - [main--], [issue/1110-comment] pull/1119

        Remove the package.json file from previous runs to avoid crashes.

        [issue/1110-comment]: https://github.com/rustwasm/wasm-pack/pull/1110#issuecomment-1059008962 [main--]: https://github.com/main--

      • Do not remove the pkg directory - [huntc], [issue/1099] pull/1110

        A recent change ensured that the pkg directory was removed as the first step of attempting to create it. Unfortunately, this caused a problem for webpack when watching the pkg directory. Webpack was unable to recover its watching and so any watch server must be restarted, which is a blocker when using it. This PR and release fixes this.

        [issue/1099]: https://github.com/rustwasm/wasm-pack/issues/1099 [huntc]: https://github.com/huntc

      • Bump regex from 1.5.4 to 1.5.6 - [dependabot], pull/1147

        Version 1.5.5 of the regex crate fixed a security bug in the regex compiler.

      • Bump openssl-src from 111.17.0+1.1.1m to 111.20.0+1.1.1o - [dependabot], pull/1146

        Bring in bug fixes from the new version of openssl-src.

        [dependabot]: https://github.com/apps/dependabot

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(5.38 MB)
    wasm-pack-v0.10.3-aarch64-unknown-linux-musl.tar.gz(4.85 MB)
    wasm-pack-v0.10.3-x86_64-apple-darwin.tar.gz(2.73 MB)
    wasm-pack-v0.10.3-x86_64-pc-windows-msvc.tar.gz(2.12 MB)
    wasm-pack-v0.10.3-x86_64-unknown-linux-musl.tar.gz(5.25 MB)
  • v0.10.2(Dec 16, 2021)

    • โœจ Features

      • Implement support for RFC 8, transitive NPM dependencies - [jpgneves], [issue/606] pull/986

        [issue/606]: https://github.com/rustwasm/wasm-pack/issues/606 [jpgneves]: https://github.com/jpgneves

    • ๐Ÿค• Fixes

      • Add support for macos aarch64 - [d3lm], [issue/913] pull/1088

        This fixes aarch64 for MacOS and will download x86_64-apple-darwin.

        [issue/913]: https://github.com/rustwasm/wasm-pack/issues/913 [d3lm]: https://github.com/d3lm

      • Add linux/arm64 to release workflow - [nacardin], [issue/1064] pull/1065

        [issue/1064]: https://github.com/rustwasm/wasm-pack/issues/1064 [nacardin]: https://github.com/nacardin

      • Force axios version - [drager], pull/1094

        Forces npm package axios to version 0.21.2 in order to get security fix for a security vulnerability present in axios before version 0.21.2.

        [drager]: https://github.com/drager

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(5.41 MB)
    wasm-pack-v0.10.2-aarch64-unknown-linux-musl.tar.gz(4.72 MB)
    wasm-pack-v0.10.2-x86_64-apple-darwin.tar.gz(2.73 MB)
    wasm-pack-v0.10.2-x86_64-pc-windows-msvc.tar.gz(1.71 MB)
    wasm-pack-v0.10.2-x86_64-unknown-linux-musl.tar.gz(5.15 MB)
  • v0.10.1(Sep 6, 2021)

  • v0.10.0(Jul 2, 2021)

    • โœจ 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.

        [pull/838]: https://github.com/rustwasm/wasm-pack/pull/838 [issue/707]: https://github.com/rustwasm/wasm-pack/issues/707

    • ๐Ÿค• 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.

        [rizary]: https://github.com/Rizary [pull/973]: https://github.com/rustwasm/wasm-pack/pull/973 [pull/1012]: https://github.com/rustwasm/wasm-pack/pull/1012 [issue/958]: https://github.com/rustwasm/wasm-pack/issues/958

      • 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!

        [pull/983]: https://github.com/rustwasm/wasm-pack/pull/983 [issue/975]: https://github.com/rustwasm/wasm-pack/issues/975 [issue/907]: https://github.com/rustwasm/wasm-pack/issues/907

      • 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.

        [pull/851]: https://github.com/rustwasm/wasm-pack/pull/851 [issue/698]: https://github.com/rustwasm/wasm-pack/issues/698

      • 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.

        [issue/837]: https://github.com/rustwasm/wasm-pack/issues/837

      • 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.

        [pull/830]: https://github.com/rustwasm/wasm-pack/pull/830 [issue/829]: https://github.com/rustwasm/wasm-pack/issues/829

    • ๐Ÿ“– Documentation

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

        [pull/1004]: https://github.com/rustwasm/wasm-pack/pull/1004 [issue/1003]: https://github.com/rustwasm/wasm-pack/issues/1003

      • Fix TOC links - Swaagie, [pull/1007]

        [pull/1007]: https://github.com/rustwasm/wasm-pack/pull/1007

      • Remove outdated TOC heading- gthb, [pull/1011]

        [pull/1011]: https://github.com/rustwasm/wasm-pack/pull/1011

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

        [pull/942]: https://github.com/rustwasm/wasm-pack/pull/942

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

        [crotwell]: https://github.com/crotwell [pull/844]: https://github.com/rustwasm/wasm-pack/pull/844 [pull/1002]: https://github.com/rustwasm/wasm-pack/pull/1002 [issue/1001]: https://github.com/rustwasm/wasm-pack/issues/1001

    • ๐Ÿ› ๏ธ Maintenance

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

        [issue/594]: https://github.com/rustwasm/wasm-pack/issues/594 [issue/979]: https://github.com/rustwasm/wasm-pack/issues/979

      • Cargo update - ashleygwilliams, [pull/800]

        [pull/800]: https://github.com/rustwasm/wasm-pack/pull/800

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

        [pull/944]: https://github.com/rustwasm/wasm-pack/pull/944 [issue/943]: https://github.com/rustwasm/wasm-pack/issues/943

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

        [pull/723]: https://github.com/rustwasm/wasm-pack/pull/723 [issue/716]: https://github.com/rustwasm/wasm-pack/issues/716

      • Fixing build error - [Pauan], pull/841

        [drager]: https://github.com/drager [Pauan]: https://github.com/Pauan

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(5.58 MB)
    wasm-pack-v0.10.0-x86_64-apple-darwin.tar.gz(2.71 MB)
    wasm-pack-v0.10.0-x86_64-pc-windows-msvc.tar.gz(2.21 MB)
    wasm-pack-v0.10.0-x86_64-unknown-linux-musl.tar.gz(5.16 MB)
  • v0.9.1(Feb 7, 2020)

    • ๐Ÿค• 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.

        [pull/687]: https://github.com/rustwasm/wasm-pack/pull/687 [issue/782]: https://github.com/rustwasm/wasm-pack/issues/782 [issue/781]: https://github.com/rustwasm/wasm-pack/issues/781

    • ๐Ÿ› ๏ธ Maintenance

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

        [pull/687]: https://github.com/rustwasm/wasm-pack/pull/687 [issue/685]: https://github.com/rustwasm/wasm-pack/issues/685

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(7.16 MB)
    wasm-pack-v0.9.1-x86_64-apple-darwin.tar.gz(2.96 MB)
    wasm-pack-v0.9.1-x86_64-pc-windows-msvc.tar.gz(2.69 MB)
    wasm-pack-v0.9.1-x86_64-unknown-linux-musl.tar.gz(5.02 MB)
  • v0.9.0(Jan 31, 2020)

    • โœจ 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

        [pull/694]: https://github.com/rustwasm/wasm-pack/pull/694

      • 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.

        [pull/623]: https://github.com/rustwasm/wasm-pack/pull/623 [issue/373]: https://github.com/rustwasm/wasm-pack/issues/373

      • 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.

        [pull/624]: https://github.com/rustwasm/wasm-pack/pull/624 [issue/620]: https://github.com/rustwasm/wasm-pack/issues/620

      • 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.

        [pull/625]: https://github.com/rustwasm/wasm-pack/pull/625 [issue/159]: https://github.com/rustwasm/wasm-pack/issues/159

      • 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.

        [pull/633]: https://github.com/rustwasm/wasm-pack/pull/633 [issue/627]: https://github.com/rustwasm/wasm-pack/issues/627

      • 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.

        [pull/690]: https://github.com/rustwasm/wasm-pack/pull/690

    • ๐Ÿค• 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.

        [issue/770]: https://github.com/rustwasm/wasm-pack/issues/770 [pull/774]: https://github.com/rustwasm/wasm-pack/pull/774 [mozilla/geckodriver/issue/1617]: https://github.com/mozilla/geckodriver/issues/1617#issuecomment-532168958

      • 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.

        [pull/660]: https://github.com/rustwasm/wasm-pack/pull/660 [issue/652]: https://github.com/rustwasm/wasm-pack/issues/652 [issue/653]: https://github.com/rustwasm/wasm-pack/issues/653

      • 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.

        [pull/658]: https://github.com/rustwasm/wasm-pack/pull/658 [issue/651]: https://github.com/rustwasm/wasm-pack/issues/651

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

        [pull/635]: https://github.com/rustwasm/wasm-pack/pull/635

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

        [pull/649]: https://github.com/rustwasm/wasm-pack/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.

        [pull/693]: https://github.com/rustwasm/wasm-pack/pull/693 [issue/692]: https://github.com/rustwasm/wasm-pack/issues/692

      • 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.

        [pull/706]: https://github.com/rustwasm/wasm-pack/pull/706 [issue/611]: https://github.com/rustwasm/wasm-pack/issues/611

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

        [pull/630]: https://github.com/rustwasm/wasm-pack/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.

        [pull/759]: https://github.com/rustwasm/wasm-pack/pull/759 [issue/757]: https://github.com/rustwasm/wasm-pack/issues/757

      • 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

        [pull/753]: https://github.com/rustwasm/wasm-pack/pull/753 [issue/752]: https://github.com/rustwasm/wasm-pack/issues/752

    • ๐Ÿ“– Documentation

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

        [issue/751]: https://github.com/rustwasm/wasm-pack/issues/751 [pull/767]: https://github.com/rustwasm/wasm-pack/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.

        [pull/640]: https://github.com/rustwasm/wasm-pack/pull/640 [issue/636]: https://github.com/rustwasm/wasm-pack/issues/636

      • 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.

        [pull/626]: https://github.com/rustwasm/wasm-pack/pull/626 [issue/370]: https://github.com/rustwasm/wasm-pack/issues/370

    • ๐Ÿ› ๏ธ Maintenance

      • Ensure that wasm-bindgen generates move assertions - fitzgen, [issue/677] [pull/683]

        wasm-pack now creates wasm-bindgen test fixtures that must generate move assertions for both free functions and methods.

        [pull/683]: https://github.com/rustwasm/wasm-pack/pull/683 [issue/677]: https://github.com/rustwasm/wasm-pack/issues/677

      • Update cargo_metadata to v0.8.0 - ThomasdenH, [pull/670]

        [pull/670]: https://github.com/rustwasm/wasm-pack/pull/670

      • Update rustfmt install snippet in PR template` - data-pup, [issue/639] [pull/664]

        rustfmt is now available on Rust's stable channel so now the wasm-pack PR template recommends installing the stable version instead of the nightly version.

        [pull/664]: https://github.com/rustwasm/wasm-pack/pull/664 [issue/639]: https://github.com/rustwasm/wasm-pack/issues/639

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(7.16 MB)
    wasm-pack-v0.9.0-x86_64-apple-darwin.tar.gz(2.96 MB)
    wasm-pack-v0.9.0-x86_64-pc-windows-msvc.tar.gz(2.69 MB)
    wasm-pack-v0.9.0-x86_64-unknown-linux-musl.tar.gz(5.02 MB)
  • v0.8.1(Apr 4, 2019)

    • ๐Ÿค• Fixes

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

        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.

        [pull/616]: https://github.com/rustwasm/wasm-pack/pull/616

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(2.89 MB)
    wasm-pack-v0.8.1-x86_64-apple-darwin.tar.gz(1.45 MB)
    wasm-pack-v0.8.1-x86_64-pc-windows-msvc.tar.gz(1.12 MB)
    wasm-pack-v0.8.1-x86_64-unknown-linux-musl.tar.gz(3.55 MB)
  • v0.8.0(Apr 2, 2019)

    • โœจ 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

        [issue/596]: https://github.com/rustwasm/wasm-pack/issues/596 [pull/599]: https://github.com/rustwasm/wasm-pack/pull/599

    • ๐Ÿค• 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.

        [pull/601]: https://github.com/rustwasm/wasm-pack/pull/601

      • 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.

        [pull/602]: https://github.com/rustwasm/wasm-pack/pull/602

    • ๐Ÿ“– 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.

        [pull/593]: https://github.com/rustwasm/wasm-pack/pull/593

      • 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!

        [issue/609]: https://github.com/rustwasm/wasm-pack/issues/609 [pull/612]: https://github.com/rustwasm/wasm-pack/pull/612 [pull/614]: https://github.com/rustwasm/wasm-pack/pull/614

    • ๐Ÿ› ๏ธ 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!

        [pull/600]: https://github.com/rustwasm/wasm-pack/pull/600

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(2.88 MB)
    wasm-pack-v0.8.0-x86_64-apple-darwin.tar.gz(1.45 MB)
    wasm-pack-v0.8.0-x86_64-pc-windows-msvc.tar.gz(1.12 MB)
    wasm-pack-v0.8.0-x86_64-unknown-linux-musl.tar.gz(3.55 MB)
  • v0.7.0(Mar 16, 2019)

    • โœจ 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!

        [pull/547]: https://github.com/rustwasm/wasm-pack/pull/547 [issue/298]: https://github.com/rustwasm/wasm-pack/issues/298

      • 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!

        [issue/525]: https://github.com/rustwasm/wasm-pack/issues/525 [pull/530]: https://github.com/rustwasm/wasm-pack/pull/530

      • 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!

        [npm package.json documentation]: https://docs.npmjs.com/files/package.json#license [rhysd]: https://github.com/rhysd [pull/527]: https://github.com/rustwasm/wasm-pack/pull/527

    • ๐Ÿค• 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!

        [pull/550]: https://github.com/rustwasm/wasm-pack/pull/550 [Mblkolo]: https://github.com/Mblkolo

      • 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.

        [issue/535]: https://github.com/rustwasm/wasm-pack/issues/535 [pull/537]: https://github.com/rustwasm/wasm-pack/pull/537

      • 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!

        [pull/521]: https://github.com/rustwasm/wasm-pack/pull/521

    • ๐Ÿ› ๏ธ 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!

        [issue/477]: https://github.com/rustwasm/wasm-pack/issues/477 [pull/478]: https://github.com/rustwasm/wasm-pack/pull/478

      • 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!

        [assert_cmd]: https://crates.io/crates/assert_cmd [pull/522]: https://github.com/rustwasm/wasm-pack/pull/522

      • 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]!

        [lfairy]: https://github.com/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!

        [issue/519]: https://github.com/rustwasm/wasm-pack/issues/519 [issue/417]: https://github.com/rustwasm/wasm-pack/issues/417

    • ๐Ÿ“– 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!

        [single location]: https://rustwasm.github.io/docs.html [See wasm-pack's master docs here]: https://rustwasm.github.io/wasm-pack/book/ [pull/565]: https://github.com/rustwasm/wasm-pack/pull/565

      • 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!

        [DebugSteven]: https://github.com/DebugSteven [pull/536]: https://github.com/rustwasm/wasm-pack/pull/536

      • 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!

        [pull/542]: https://github.com/rustwasm/wasm-pack/pull/542

      • 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!

        [drager]: https://github.com/drager [ashleygwilliams]: https://github.com/ashleygwilliams [fitzgen]: https://github.com/fitzgen [alexcrichton]: https://github.com/alexcrichton [huangjj27]: https://github.com/huangjj27 [pull/539]: https://github.com/rustwasm/wasm-pack/pull/539

      • 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!

        [pull/514]: https://github.com/rustwasm/wasm-pack/pull/514 [pull/516]: https://github.com/rustwasm/wasm-pack/pull/516

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(2.88 MB)
    wasm-pack-v0.7.0-x86_64-apple-darwin.tar.gz(1.45 MB)
    wasm-pack-v0.7.0-x86_64-pc-windows-msvc.tar.gz(1.12 MB)
    wasm-pack-v0.7.0-x86_64-unknown-linux-musl.tar.gz(3.55 MB)
  • v0.6.0(Jan 15, 2019)

    • โœจ 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
        # 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!

        [cargo profile documentation]: https://doc.rust-lang.org/cargo/reference/manifest.html#the-profile-sections [fitzgen]: https://github.com/fitzgen [alexcrichton]: https://github.com/alexcrichton [csmoe]: https://github.com/csmoe [mstallmo]: https://github.com/mstallmo [issue/153]: https://github.com/rustwasm/wasm-pack/issues/153 [issue/160]: https://github.com/rustwasm/wasm-pack/issues/160 [pull/440]: https://github.com/rustwasm/wasm-pack/pull/440

      • 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.

        [torkve]: https://github.com/torkve [issue/455]: https://github.com/rustwasm/wasm-pack/issues/455 [pull/461]: https://github.com/rustwasm/wasm-pack/pull/461

      • 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

        [pull/444]: https://github.com/rustwasm/wasm-pack/pull/444

      • 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!

        [pull/453]: https://github.com/rustwasm/wasm-pack/pull/453

      • 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!

        [issue/305]: https://github.com/rustwasm/wasm-pack/issues/305 [pull/430]: https://github.com/rustwasm/wasm-pack/pull/430

      • 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.

        [pull/426]: https://github.com/rustwasm/wasm-pack/pull/426

    • ๐Ÿค• 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.

        [issue/277]: https://github.com/rustwasm/wasm-pack/issues/277 [pull/489]: https://github.com/rustwasm/wasm-pack/pull/489

      • 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.

        [pull/484]: https://github.com/rustwasm/wasm-pack/pull/484

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

        [issue/486]: https://github.com/rustwasm/wasm-pack/issues/486 [pull/487]: https://github.com/rustwasm/wasm-pack/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.

        [pull/396]: https://github.com/rustwasm/wasm-pack/pull/396

      • 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!

        [pull/411]: https://github.com/rustwasm/wasm-pack/pull/411

      • 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.:

        name = "hello-wasm"
        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!

        [issue/339]: https://github.com/rustwasm/wasm-pack/issues/339 [pull/435]: https://github.com/rustwasm/wasm-pack/pull/435

      • 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?)

        [pull/424]: https://github.com/rustwasm/wasm-pack/pull/424

      • 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!

        [pull/417]: https://github.com/rustwasm/wasm-pack/pull/417

    • ๐Ÿ› ๏ธ 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.

        [pull/434]: https://github.com/rustwasm/wasm-pack/pull/434

      • 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 will be considering publishing it in the near future!

        [issue/384]: https://github.com/rustwasm/wasm-pack/issues/384 [pull/415]: https://github.com/rustwasm/wasm-pack/pull/415

      • 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.

        [pull/436]: https://github.com/rustwasm/wasm-pack/pull/436

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

        [pull/431]: https://github.com/rustwasm/wasm-pack/pull/431

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

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

        [pull/408]: https://github.com/rustwasm/wasm-pack/pull/408

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

        [issue/380]: https://github.com/rustwasm/wasm-pack/issues/380 [pull/389]: https://github.com/rustwasm/wasm-pack/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!

        [issue/346]: https://github.com/rustwasm/wasm-pack/issues/346 [pull/490]: https://github.com/rustwasm/wasm-pack/pull/490

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

        [pull/485]: https://github.com/rustwasm/wasm-pack/pull/485

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(4.85 MB)
    wasm-pack-v0.6.0-x86_64-apple-darwin.tar.gz(1.84 MB)
    wasm-pack-v0.6.0-x86_64-pc-windows-msvc.tar.gz(1.75 MB)
    wasm-pack-v0.6.0-x86_64-unknown-linux-musl.tar.gz(3.97 MB)
  • v0.5.1(Oct 9, 2018)

    • ๐Ÿค• 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!

        [pull/392]: https://github.com/rustwasm/wasm-pack/pull/392

      • 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.

        [pull/394]: https://github.com/rustwasm/wasm-pack/pull/394

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

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

        [issue/291]: https://github.com/rustwasm/wasm-pack/issues/291 [pull/387]: https://github.com/rustwasm/wasm-pack/pull/387

      • 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.

        [pull/378]: https://github.com/rustwasm/wasm-pack/pull/378

      • 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.

        [fitzgen]: https://github.com/fitzgen [mstallmo]: https://github.com/mstallmo [alexcrichton]: https://github.com/alexcrichton [issue/280]: https://github.com/rustwasm/wasm-pack/issues/280 [pull/401]: https://github.com/rustwasm/wasm-pack/pull/401

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(4.51 MB)
    wasm-pack-v0.5.1-x86_64-apple-darwin.tar.gz(1.85 MB)
    wasm-pack-v0.5.1-x86_64-pc-windows-msvc.tar.gz(1.65 MB)
    wasm-pack-v0.5.1-x86_64-unknown-linux-musl.tar.gz(4.48 MB)
  • v0.5.0(Sep 25, 2018)

    • โœจ 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!

        [fitzgen]: https://github.com/fitzgen [pull/246]: https://github.com/rustwasm/wasm-pack/pull/246

      • ๐Ÿฑ 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!

          [issue/309]: https://github.com/rustwasm/wasm-pack/issues/309 [pull/312]: https://github.com/rustwasm/wasm-pack/pull/312

      • ๐Ÿ› ๏ธ 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.

          [issue/188]: https://github.com/rustwasm/wasm-pack/issues/188 [pull/216]: https://github.com/rustwasm/wasm-pack/pull/216

        • 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!)

          [pull/282]: https://github.com/rustwasm/wasm-pack/pull/282

      • ๐ŸŽ 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!

          [pull/327]: https://github.com/rustwasm/wasm-pack/pull/327

        • --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.

          [pull/299]: https://github.com/rustwasm/wasm-pack/pull/299

      • โœ… 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!

          [pull/353]: https://github.com/rustwasm/wasm-pack/pull/353

        • 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

          [issue/146]: https://github.com/rustwasm/wasm-pack/issues/146 [pull/244]: https://github.com/rustwasm/wasm-pack/pull/244 [pull/324]: https://github.com/rustwasm/wasm-pack/pull/324

        • 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!

          [issue/303]: https://github.com/rustwasm/wasm-pack/issues/303 [pull/330]: https://github.com/rustwasm/wasm-pack/pull/330

      • 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.

          [issue/147]: https://github.com/rustwasm/wasm-pack/issues/147 [pull/301]: https://github.com/rustwasm/wasm-pack/pull/301

        • 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

      • testing fixture strategy improvements - [fitzgen], pull/211 [pull/323]

        [pull/323]: https://github.com/rustwasm/wasm-pack/pull/323

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

        [pull/216]: https://github.com/rustwasm/wasm-pack/pull/216

      • update dependencies - ashleygwilliams, issue/319 [pull/320]

        [pull/320]: https://github.com/rustwasm/wasm-pack/pull/320

    • ๐Ÿ“– 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.

        [pull/296]: https://github.com/rustwasm/wasm-pack/pull/296

      • 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]

        [issue/325]: https://github.com/rustwasm/wasm-pack/issues/325 [pull/328]: https://github.com/rustwasm/wasm-pack/pull/328

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-init.exe(4.34 MB)
    wasm-pack-v0.5.0-x86_64-apple-darwin.tar.gz(1.82 MB)
    wasm-pack-v0.5.0-x86_64-pc-windows-msvc.tar.gz(1.61 MB)
    wasm-pack-v0.5.0-x86_64-unknown-linux-musl.tar.gz(4.44 MB)
  • v0.4.2(Jul 25, 2018)

    • ๐Ÿค• 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!

        [turboladen]: https://github.com/turboladen [issue/221]: https://github.com/rustwasm/wasm-pack/issues/221 [pull/224]: https://github.com/rustwasm/wasm-pack/pull/224

      • 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]!

        [pull/198]: https://github.com/rustwasm/wasm-pack/pull/198 [pack and publish docs]: https://github.com/rustwasm/wasm-pack/blob/05e4743c22b57f4c4a1bfff1df1d2cc1a595f523/docs/pack-and-publish.md

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

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-v0.4.2-x86_64-apple-darwin.tar.gz(1.17 MB)
    wasm-pack-v0.4.2-x86_64-unknown-linux-musl.tar.gz(2.52 MB)
  • v0.4.1(Jul 14, 2018)

    • ๐Ÿค• 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.

        [Brooooooklyn]: https://github.com/Brooooooklyn [issue/199]: https://github.com/rustwasm/wasm-pack/issues/199 [pull/205]: https://github.com/rustwasm/wasm-pack/pull/205 [pull/197]: https://github.com/rustwasm/wasm-pack/pull/197 [pull/200]: https://github.com/rustwasm/wasm-pack/pull/200

    • ๐Ÿ› ๏ธ 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!

        [pull/193]: https://github.com/rustwasm/wasm-pack/pull/193 [v0.3.0]: https://github.com/rustwasm/wasm-pack/blob/master/CHANGELOG.md#-030

    • ๐Ÿ“– 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!

        [pull/208]: https://github.com/rustwasm/wasm-pack/pull/208

      • 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!

        [pull/202]: https://github.com/rustwasm/wasm-pack/pull/202

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-v0.4.1-x86_64-apple-darwin.tar.gz(1.15 MB)
    wasm-pack-v0.4.1-x86_64-unknown-linux-musl.tar.gz(2.50 MB)
  • v0.4.0(Jun 18, 2018)

    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]!

        [issue/188]: https://github.com/ashleygwilliams/wasm-pack/issues/188 [pull/186]: https://github.com/ashleygwilliams/wasm-pack/pull/186

        • 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!

          [pull/151]: https://github.com/ashleygwilliams/wasm-pack/pull/151

        • 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!

        [issue/126]: https://github.com/ashleygwilliams/wasm-pack/issues/126 [clanehin]: https://github.com/clanehin

    • โœ… 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.

        [kendromelon]: https://github.com/kedromelon [pull/150]: https://github.com/ashleygwilliams/wasm-pack/pull/150

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

        [pull/162]: https://github.com/ashleygwilliams/wasm-pack/pull/162

      • 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!

        [issue/171]: https://github.com/ashleygwilliams/wasm-pack/issues/171 [pull/172]: https://github.com/ashleygwilliams/wasm-pack/pull/172

    ๐Ÿค• 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.

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-v0.4.0-x86_64-apple-darwin.tar.gz(1.16 MB)
    wasm-pack-v0.4.0-x86_64-unknown-linux-musl.tar.gz(2.48 MB)
  • v0.3.1(Jun 5, 2018)

    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!

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-v0.3.1-x86_64-apple-darwin.tar.gz(1.14 MB)
    wasm-pack-v0.3.1-x86_64-unknown-linux-musl.tar.gz(2.46 MB)
  • v0.3.0(May 31, 2018)

    โœจ 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!!

    Source code(tar.gz)
    Source code(zip)
    wasm-pack-v0.3.0-x86_64-apple-darwin.tar.gz(1.14 MB)
    wasm-pack-v0.3.0-x86_64-unknown-linux-musl.tar.gz(2.46 MB)
  • v0.2.0(Apr 27, 2018)

    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!

    Source code(tar.gz)
    Source code(zip)
Rust and WebAssembly
๐Ÿฆ€ + ๐Ÿ•ธ๏ธ = ๐Ÿ’–
Rust and WebAssembly
Distribute a wasm SPA as HTML by wrapping it as a polyglot "html+wasm+zip"

A packer that adds a webpage to WASM module, making it self-hosted! Motivation At the moment, Browsers can not execute WebAssembly as a native single

Andreas Molzer 3 Jan 2, 2023
zzhack-cli is a Command Tool to help you quickly generate a WASM WebApp with simple configuration and zero code

English | ไธญๆ–‡ๆ–‡ๆกฃ zzhack-cli is a Command Tool that can help you quickly generate a WASM WebApp with simple configuration and zero code. It's worth menti

null 17 Feb 9, 2023
Rust based WASM/JS bindings for ur-rust

ur-wasm-js WASM/JS bindings for the ur-rust rust library Getting started Installation Either build the library yourself with wasm-pack or install for

Lightning Digital Entertainment 5 Feb 28, 2024
Gun port in rust & wasm

gun-rs-wasm Rust & WASM port of Gun. For a non-wasm version, check out gun-rs Example (source) Use npm install rusty-gun import { Node as Gun } from "

Martti Malmi 39 Dec 19, 2022
Parametric surfaces drawn using the Rust + WASM toolchain with WebGL, React, and TypeScript.

Parametric Surfaces in the Browser My.Movie.3.mp4 Wanted to experiment with WebGL using the Rust + WASM toolchain, with React and TypeScript to glue e

Benji Nguyen 45 Oct 21, 2022
Rust implementation of the Mina protocol, targeting Wasm and ARM architectures.

Mina-rs An implementation of Mina protocol in Rust, with focus on web and Wasm compatibility ** As you can probably tell this is a WIP! Don't use for

ChainSafe 157 Dec 12, 2022
A self-guided learning project that includes Rust + Wasm together

A self-guided learning project that includes Rust + Wasm together. Who knows, maybe Typescript and React joins too..

M.Yavuz Yagis 1 Feb 14, 2022
WASM bindings for React - enables you to write and use React components in Rust

This library enables you to write and use React components in Rust, which then can be exported to JS to be reused or rendered.

Yichuan Shen 55 Dec 24, 2022
Realtime audio processing / synthesis using Rust/WASM in the browser.

Rust Audio About This repo is my investigation into using Rust for creative audio coding on various platforms (e.g. desktop, web, etc.), but especiall

Austin Theriot 30 Jan 5, 2023
Rust bindings for the Wasm spec interpreter.

wasm-spec-interpreter This project shows how to use ocaml-interop to call into the Wasm spec interpreter. There are several steps to making this work:

Bytecode Alliance 9 Aug 23, 2022
Spine runtime for Rust (and wasm!) transpiled from the official C Runtime.

rusty_spine Spine runtime for Rust (and wasm!) transpiled from the official C Runtime. Supports Spine 4.1. [dependencies] rusty_spine = "0.4.0" Onlin

jabu 12 Dec 17, 2022
Simple devcontainer for Rust + WASM development

Devcontainer WASM-Rust Simple devcontainer for Rust development Usage Github Codespaces Just click the button: Visual Studio Code Note this assumes th

null 2 Dec 22, 2022
Create WASM plugins easily in Rust.

Scotch Library for creating WASM plugins with Rust. Scotch allows you to pass complex types to/from functions in WASM plugins. It achieves that by enc

null 23 Feb 1, 2023
Fast regex in Rust for Apache Arrow, compiled to WASM

Rust regex in wasm I have been looking for a fast regular expression library in Javascript that runs on Apache Arrow for a few years. Arrow uses UTF-8

Nomic AI 3 May 3, 2023
Facilitating high-level interactions between Wasm modules and JavaScript

wasm-bindgen Facilitating high-level interactions between Wasm modules and JavaScript. Guide | API Docs | Contributing | Chat Built with ?? ?? by The

Rust and WebAssembly 5.9k Jan 8, 2023
Install `wasm-pack` by downloading the executable

wasm-pack-action Install wasm-pack by downloading the executable (much faster than cargo install wasm-pack, seconds vs minutes). Usage - uses: jetli/w

Jet Li 33 Nov 23, 2022
`wasm-snip` replaces a WebAssembly function's body with an `unreachable`

wasm-snip wasm-snip replaces a Wasm function's body with an unreachable instruction. API Docs | Contributing | Chat Built with ?? ?? by The Rust and W

Rust and WebAssembly 177 Dec 28, 2022
gc-sections for wasm

wasm-gc Note: you probably don't need to use this project. This project is no longer necessary to run by hand, nor do you need the wasm-gc executable

Alex Crichton 245 Oct 22, 2022
List the symbols within a wasm file

wasm-nm List the symbols within a wasm file. Library Executable License Contributing Executable To install the wasm-nm executable, run $ cargo install

Nick Fitzgerald 38 Nov 6, 2022