wasm-bindgen/wasm-pack
61.8
Adequate · 29 September 2026
3.7k
lines of production code
Rust
primary language
2
measurements over time
What this system is
This system is a command-line interface tool designed to streamline the development lifecycle of Rust-to-WebAssembly projects. It automates the process of building, testing, and publishing Rust libraries as WebAssembly binaries, supporting multiple execution environments including Node.js, browsers, and Deno. The tool handles platform-specific binary installation, manages WebDriver dependencies for browser-based testing, and generates standardized npm package manifests for various module types.
How it got here
2018 — Initial release and core feature expansion
9 changes.
This period marks the initial release of wasm-pack, establishing the foundational CLI structure and comprehensive documentation. It focused on delivering core functionality, including project scaffolding, WebAssembly building, and npm publishing, while introducing critical features like browser-based testing and support for Deno. The work also involved refining manifest generation for various module targets and expanding integration test coverage to ensure robustness.
2019–2026 — platform support and installation modernization
5 changes.
The project expanded its platform compatibility by adding support for tier-3 wasm64 targets and aarch64 architectures across macOS and Linux. Installation logic was modernized by replacing deprecated dependencies with native scripts and modular components, ensuring reliable binary distribution for diverse environments. Additionally, a starter project template was introduced to streamline WebAssembly development workflows.
Features
Add --access flag to control npm package visibility
The publish command now supports an --access flag (accepting 'public' or 'restricted') to explicitly set the access level for npm packages, ensuring scoped packages can be published with restricted visibility as required by npm. This change introduces the access.rs module to parse and validate these levels and updates the publish logic to pass this setting to the underlying npm publish operation.
src/command/publish · high confidence
Added wasm-pack project template
The repository now includes a \wasm-pack-template\ directory containing a starter project for Rust and WebAssembly development. This template provides the necessary structure to compile Rust libraries into WebAssembly and publish them to NPM, including configuration for \cargo-generate\, dual Apache-2.0/MIT licensing, a basic \greet\ function using \wasm-bindgen\, panic hook utilities, and a sample web test.
wasm-pack-template · high confidence
Initial project scaffolding and documentation
The repository is initialized with core project files, including a \.gitignore\ to exclude build artifacts and IDE configurations, a \CHANGELOG.md\ tracking version history, and standard legal documents (\LICENSE-APACHE\, \LICENSE-MIT\). A comprehensive \README.md\ is added to describe the tool's purpose, prerequisites, and commands, alongside \CONTRIBUTING.md\ and \CODE\_OF\_CONDUCT.md\ to guide community participation. This entry establishes the foundational structure and documentation for the project.
(repo-wide) · high confidence
Initial release of wasm-pack
This is the first release of wasm-pack, a CLI tool designed to simplify the workflow for building, testing, and publishing Rust/Wasm projects. It provides commands to build WebAssembly binaries using wasm-bindgen, run tests, and publish packages to npm. The tool includes features for automatic binary installation, progress reporting with emojis, and support for various build targets like Node.js, Web, and Deno.
src · high confidence
New \`wasm-pack test\` command and \`generate\` command for scaffolding projects
This release introduces two new CLI commands. The \wasm-pack test\ command allows you to run Rust tests in Node.js or browsers (Chrome, Firefox, Safari) with support for headless mode, specific driver paths, and extra cargo options. The \wasm-pack generate\ command (aliased as \new\) scaffolds a new Rust WASM project from a template using \cargo-generate\. Additionally, the \build\ command now supports a \--target deno\ option for generating Deno-compatible modules.
src/command · high confidence
New wasm-pack test subcommand for running Wasm tests
A new \wasm-pack test\ subcommand has been added, allowing users to run \cargo test\ against Rust crates compiled to WebAssembly. This feature includes infrastructure for managing WebDriver binaries (Chrome, Firefox, Safari) to support browser-based testing, and utilizes the \child::run\ helper to execute the test commands.
src/test · high confidence
Behavioural changes
Native binary installation replaces deprecated package
The npm package now installs the wasm-pack binary directly from GitHub releases instead of relying on the deprecated \binary-install\ package. This new installer script supports Windows, Linux, and macOS, including arm64 architectures (Apple Silicon and Linux ARM64), and automatically downloads and extracts the correct binary for the user's platform.
npm · high confidence
Refactored NPM manifest generation into modular, target-specific structs
The NPM manifest generation logic has been reorganized into separate modules for CommonJS, ES Modules, and No Modules targets. This change introduces distinct serialization structures for each target type, allowing for more precise control over the generated package.json fields. Specifically, the ES Modules manifest now includes a \sideEffects\ field (mapped from \side\_effects\) and explicitly sets the \type\ field to \module\, while the CommonJS and No Modules manifests retain their respective \main\ and \browser\ entry points. This modular approach ensures that each output format adheres strictly to its specific requirements, improving the accuracy of the generated NPM packages.
src/manifest/npm · high confidence
Refactored installation logic into modular components with improved platform support
The installation subsystem has been restructured into distinct modules (\arch\, \krate\, \mode\, \os\, \tool\) to improve maintainability and clarity. This change introduces explicit support for macOS aarch64 and Linux aarch64 targets, ensuring prebuilt binaries are correctly downloaded for these architectures. It also replaces the \curl\ dependency with \ureq\ for HTTP requests, adds proxy environment support, and includes a \--no-gitignore\ flag for the generate command. The logic now cleanly separates architecture detection, OS identification, and tool-specific download URLs, enhancing reliability across different platforms.
src/install · high confidence
Support for custom build profiles and enhanced manifest parsing
The manifest module now supports defining custom build profiles (dev, release, profiling, and custom) via \Cargo.toml\ under \\[package.metadata.wasm-pack.profile\]\, allowing users to configure wasm-bindgen and wasm-opt settings per profile. It also improves manifest reading by respecting \package.readme\ and \license-file\ fields from Cargo.toml, copying the \homepage\ field to package.json, and handling workspace inheritance. Additionally, the module includes better error reporting for typos in wasm-pack configuration keys using Levenshtein distance and rate-limits version check requests to avoid API abuse.
src/manifest · high confidence
Support for tier-3 wasm64 targets and arbitrary target verification
The build module now supports compiling for tier-3 targets like wasm64-unknown-unknown by verifying nightly toolchain prerequisites and automatically installing the rust-src component if missing, rather than relying on prebuilt sysroots. Additionally, target availability checks have been rewritten to use rustc's target-libdir for more robust detection, and the build process now correctly handles relative paths in extra options by converting them to absolute paths before passing them to cargo.
src/build · high confidence
Test coverage
Added WebDriver binary installation tests; Expanded integration test coverage for wasm-pack core features; New test utility modules for fixtures, manifests, and file operations.
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
How this codebase got here
Score
- CAI 64 → 62 (-2.1)
- Rubric changed (rubric-2026.09.9 → rubric-2026.09.17) — scores are not directly comparable.
Lenses
- Code Health 95 → 95 (+0.0)
- Architecture 100 → 100 (-0.1)
- Maturity 56 → 55 (-1.0)
- Readiness 73 → 67 (-6.4)
- Security 55 → 69 (+14.4)
- Performance 60 (new)
Resolved (6)
- Critical CVE: [CVE redacted] (npm/yarn.lock)
- Documentation: written for insiders (docs/src/prerequisites/considerations.md)
- High CVE: [CVE redacted] (npm/yarn.lock)
- High CVE: [CVE redacted] (npm/yarn.lock)
- Medium CVE: [CVE redacted] (npm/yarn.lock)
- Medium CVE: [CVE redacted] (npm/yarn.lock)
New (5)
- Ambiguous construction vs parsing: new takes a crate path and out_name, while parse_crate_data takes a manifest path. It is unclear if new internally calls parse_crate_data or if they represent distinct initialization flows (e.g., one for fresh creation, one for loading existing). The naming convention mixes constructor style (new) with action style (parse_...).
- Dependency hygiene PARTLY measured — Cargo dependencies read, dependency currency not (crates.io unreachable)
- Inverted test pyramid
- Medium vulnerability: RUSTSEC-2026-0285 (Cargo.lock)
- Redundant version inspection: get_cli_version retrieves the version string, while check_version likely compares it against an expected value. These are closely related operations that could be unified into a single get_version method returning a struct or result containing the version, with validation logic separated or handled by the caller.
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
Survey your own repository
wasm-bindgen/wasm-pack was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.
About this page
- The score is its most recent published measurement, taken on 29 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
- Measured at commit e33b17ae4168f79fc510d33131948aa8de92a108 — the exact code this score is about.
- Scored under rubric-2026.09.17 — the same rubric and the same method as every other entry in this index.
- Measured by watchdog.canine.dev using codehealth-analyzer preprod-705631bb727e.