wasm-pack builds a Rust crate into an npm WebAssembly package

Four verbs carry a crate from template to registry

wasm-pack exposes four commands and each one covers a distinct step. `new` generates a RustWasm project from a template. `build` turns an existing rustwasm crate into an npm wasm package, which is the artifact your JavaScript side imports. `test` runs browser tests. `pack` writes a tarball of that package, and `publish` sends it to a registry. The first run after you have a crate is a single verb:

wasm-pack build

The stated goal is being a one stop shop for rust generated WebAssembly that you want to interop with JavaScript, either in the browser or with Node.js. `build` is the point of the whole tool: it is what turns a `Cargo.toml` into something publishable to the npm registry or usable alongside the JavaScript packages you already ship through webpack.

`wasm-pack test` means browser tests, not your Rust unit suite

The verb is named `test`, and the description attached to it in the command list is a single line: Run browser tests. That is all the README says about it; flags and runners are covered on the linked `test` command page, not in the README.

The stated Rust 1.30.0 floor sits next to an edition 2021 manifest

The prerequisites line reads that this project requires Rust 1.30.0 or later. The manifest at the repository root tells a different story in practice. It sets `edition = "2021"` and pulls in crates far newer than that era, including `clap` 4.2.5, `ureq` 2.12.1, `anyhow` 1.0.100 and `serde` 1.0.228. A toolchain old enough to satisfy the stated floor cannot compile a 2021 edition crate, so the prerequisite sentence is stale for anyone building wasm-pack from source. The cost lands on contributors rather than on people who install a binary: someone following the line literally runs into edition and dependency errors before wasm-pack ever executes, and the real minimum becomes whatever the current dependency tree demands.

RUST_LOG is the only knob, and it is an env_logger one

wasm-pack uses `env_logger` to produce logs, and the environment variable `RUST_LOG` is the documented way to set the level. The README offers exactly one example:

RUST_LOG=info wasm-pack build

There is no `--verbose` or `--quiet` flag listed alongside the commands, and no per command verbosity override. Because it is an environment variable, it can be set for a single invocation, as the README's own `RUST_LOG=info wasm-pack build` example does. The manifest also wires `env_logger` in with `default-features = false` at version 0.11.8, and nothing in the README says what that leaves enabled, so the shape of the output is not something the documentation commits to.

No proxy or offline path on paper, an HTTP client in the manifest

Installation is not a line in the README. The prerequisites section links out to a separate installer page at wasm-bindgen.github.io/wasm-pack/installer, and that page is where any install command lives. What the manifest shows is what has to be true for that to work behind a restricted network: it depends on `binary-install`, and on `ureq` 2.12.1 with the `json` and `socks-proxy` features enabled. A socks-proxy feature is a deliberate accommodation for proxied networks, yet no proxy variable and no proxy flag appear in the command list. The reader on a locked down machine therefore has no documented way to point wasm-pack at the proxy its own HTTP client can already speak. The missing offline install is the larger gap, since the repository does ship `src/` and `Cargo.toml` for a source build that no line of the README mentions.

Publishing is a separate step with no documented registry credentials

`pack` and `publish` are grouped into one entry in the command list: create a tarball of your rustwasm pkg and/or publish to a registry. Two things follow from that grouping. First, packaging is not implicit in `build`. A local tarball is a deliberate second step. Second, authentication is unmentioned. There is no login command, no scope note, no npm token discussion and no registry flag in the README, even though publishing to the npm registry is the stated target. The consequence falls on whoever runs the release: credentials have to arrive through the surrounding pipeline, and wasm-pack offers no documented hook for it.

Version 0.15.0 in the manifest, released in May 2026

The manifest pins `version = "0.15.1"`, matching the v0.15.1 tag dated 2026-10-30. Earlier, v0.15.0 landed on 2026-05-15 and v0.14.0 on 2026-01-20, about four months apart. The most recent push to the default branch `master` is dated 2026-10-30. The project moves, but in bursts. What none of that tells you is which wasm-bindgen version a given release pairs with. The repository lives under the wasm-bindgen organization and its documentation is hosted on wasm-bindgen.github.io, so the two are plainly connected, yet the README leaves the pairing to the reader.

Two names in governance, and no issue tracker in the README

The governance note names two people: the project was started by ashleygwilliams and is maintained by drager. The manifest lists the authors as Ashley Williams and Jesper Håkansson. The README never says where to file a problem. The links it does offer are a documentation site, a contribution policy in CONTRIBUTING.md, and a Discord channel. No issue tracker is linked anywhere, so a reproducible build failure tends to become a chat message. The repository itself is better organized than the README: alongside `src/` sit `tests/`, `docs/`, an `npm/` directory, `wasm-pack-template/`, CHANGELOG.md, RELEASE_CHECKLIST.md, CODE_OF_CONDUCT.md and clippy.toml.

Editorial conclusion

Use wasm-pack when you ship or consume Rust as WebAssembly through npm and want one command to produce the package. Skip it when you need a documented offline install, a proxy flag, or a registry login path, because the README covers none of those. Before you commit, check which wasm-bindgen version your release pairs with, because the README never states it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. wasm-bindgen/wasm-pack on GitHub