If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/wasm-bindgen/wasm-pack shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1w ago
• 21+ active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 58% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live wasm-bindgen/wasm-pack repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/wasm-bindgen/wasm-pack.

What it runs against: a local clone of wasm-bindgen/wasm-pack — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in wasm-bindgen/wasm-pack | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 39 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of wasm-bindgen/wasm-pack. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/wasm-bindgen/wasm-pack.git
#   cd wasm-pack
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of wasm-bindgen/wasm-pack and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "wasm-bindgen/wasm-pack(\\.git)?\\b" \\
  && ok "origin remote is wasm-bindgen/wasm-pack" \\
  || miss "origin remote is not wasm-bindgen/wasm-pack (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 39 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~9d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/wasm-bindgen/wasm-pack"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

wasm-pack is a CLI tool and build orchestrator that automates the Rust-to-WebAssembly compilation pipeline, producing npm-ready packages with JavaScript interop glue code. It wraps wasm-bindgen, wasm-opt, and cargo to handle the entire workflow from Rust source to publishable npm artifacts, eliminating manual build step complexity for WebAssembly projects. Single-crate monolith structure: src/ contains command handlers (build, test, new, pack, publish) and a manifest module for Cargo.toml manipulation. CLI entry point via clap derive macros in main.rs. Thin wrapper around external binaries (cargo, wasm-bindgen, wasm-opt) installed via binary-install. Heavy use of anyhow for error handling and serde for config serialization.

Rust developers who want to publish reusable WebAssembly libraries to npm and integrate them with JavaScript/TypeScript projects in browsers or Node.js, without managing separate build configurations for wasm-bindgen, optimization, and package metadata.

Production-ready and actively maintained. Version 0.14.0 with comprehensive test infrastructure (.github/workflows/test.yml), published to crates.io, full documentation site (docs/src/SUMMARY.md), and clear RELEASE_CHECKLIST.md. Last data shows active dependency maintenance (latest anyhow 1.0.100, clap 4.2.5) and organized CI/CD workflows.

Low risk for core functionality but single maintainer (@drager) on the governance side poses continuity risk. Moderate dependency surface (25+ direct deps including binary-install for managing external tools, which adds remote-fetch complexity). No visible breaking changes in CHANGELOG.md snippet, but as a tool in the Rust ecosystem it inherits WASM spec evolution risk.

Active maintenance with recent dependency updates (env_logger 0.11.8, semver 1.0.27, clap 4.2.5). CI workflows in .github/workflows/ show test.yml, release.yml, and book.yml automation. No visible feature branch evidence in file list, but organized issue templates (bug_report.md, feature_request.md) suggest structured contribution process.

git clone https://github.com/wasm-bindgen/wasm-pack.git && cd wasm-pack && cargo build --release. Requires Rust 1.30.0+. Optional: RUST_LOG=info cargo run to see logging output.

Daily commands: cargo run -- build (builds current project to pkg/), cargo run -- new my-project (generates template), cargo run -- test (runs browser tests via wasm-bindgen-test). Set RUST_LOG=debug for detailed output. See docs/src/commands/ for full command documentation.

• src/main.rs: CLI entry point with clap derive macro definitions for all wasm-pack subcommands (build, test, new, pack, publish)
• Cargo.toml: Lists all 25+ production dependencies including binary-install, cargo_metadata, serde, and defines the tool version 0.14.0
• src/manifest.rs: Handles reading/writing Cargo.toml manifest files and wasm-pack-specific metadata injection
• .github/workflows/test.yml: CI pipeline defining how all tests run across platforms and Rust versions
• docs/src/commands/build.md: User-facing documentation for the primary 'build' command workflow
• src/lib.rs: Library interface exposing core wasm-pack functionality for programmatic use

Command implementations live in src/ as modules matching docs/src/commands/ structure. To add a new command: create a module in src/, implement command handler using clap derive attributes, wire into main CLI dispatcher. Manifest/Cargo.toml manipulation is in the manifest module. Binary tool invocations happen through the binary-install wrapper. Tests are in tests/ (using assert_cmd for CLI testing). Documentation lives in docs/src/commands/ as Markdown.

wasm-pack relies on binary-install to download wasm-bindgen and wasm-opt binaries at runtime—network access is required and binary URLs are versioned. Rust 1.30.0+ is a hard requirement (checked in docs). The tool assumes wasm-bindgen's WebAssembly output contract; breaking changes in wasm-bindgen can silently produce incompatible packages. RUST_LOG=info may be needed to debug tool integration issues since errors from sub-processes (cargo, wasm-opt) are sometimes opaque. GitHub Actions workflows pin tool versions (see release.yml) which can drift from local development environment.

• WebAssembly Text Format (WAT) and Binary (WASM) — wasm-pack outputs .wasm binary modules and generates JavaScript glue code to call them; understanding WAT and the binary format helps debug linker errors and binary size issues
• Foreign Function Interface (FFI) and Type Marshaling — wasm-bindgen (which wasm-pack orchestrates) performs complex FFI marshaling between Rust's type system and JavaScript's dynamic types; critical for understanding what 'interop' means in the output
• npm Package Metadata and Dual-Mode Distribution — wasm-pack generates package.json, publishes to npm, and creates dual CommonJS/ES module outputs; understanding npm module resolution affects how downstream JS apps consume the WASM package
• Binaryen and WASM Optimization — wasm-pack runs wasm-opt (from Binaryen) to shrink binary size and improve runtime performance; understanding optimization levels and passes helps diagnose slow WASM execution
• Cargo Metadata and Workspace Inheritance — wasm-pack reads Cargo.toml via cargo_metadata to inject wasm-pack-specific config (library type, example build targets); understanding Cargo's manifest structure is essential for packaging control
• Binary Installation and Vendoring — wasm-pack uses binary-install to download pre-built wasm-opt and wasm-bindgen binaries rather than building from source; this design trades build time for network dependency and version lock management

• rustwasm/wasm-bindgen — The core JavaScript ↔ Rust FFI generator that wasm-pack wraps; wasm-pack orchestrates wasm-bindgen compilation as a subprocess
• rustwasm/wasm-opt.rs — Rust bindings to wasm-opt (Binaryen's optimizer); wasm-pack uses this binary to minimize WASM artifact size
• rustwasm/book — The Rust and WebAssembly learning guide that documents the entire ecosystem wasm-pack is part of, including architecture patterns
• thedodd/yew — A frontend framework for Rust that targets WASM and commonly uses wasm-pack for building and publishing components
• bevyengine/bevy — Game engine in Rust that supports WASM targets and uses wasm-pack workflows for browser deployment

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for wasm-pack init and new commands

The repo has test.yml workflow and dev-dependencies for testing (assert_cmd, predicates, serial_test, tempfile), but based on the file structure, there's no dedicated test suite visible for the init and new commands which are critical user-facing features. These commands scaffold projects and have complex interactions with file systems and templates. Adding integration tests using assert_cmd would catch regressions early and document expected behavior.

• [ ] Create tests/integration/init_command.rs to test wasm-pack init with various project configurations
• [ ] Create tests/integration/new_command.rs to test wasm-pack new template generation and validation
• [ ] Test both success paths (valid Cargo.toml, correct file generation) and error cases (missing fields, invalid configs)
• [ ] Verify generated projects can build without errors
• [ ] Update test.yml workflow to run integration tests if not already included

Document and add CI validation for docs/src/commands/ completeness

The docs/src/commands/ directory has build.md, index.md, init.md, new.md, pack-and-publish.md, and test.md, but there's no documented validation that all wasm-pack commands have corresponding documentation. A new contributor could add a GitHub workflow that validates every CLI command has a corresponding .md file, and add missing documentation pages (e.g., for any undocumented flags or commands revealed by wasm-pack --help).

• [ ] Run wasm-pack --help and wasm-pack <command> --help to extract all available commands
• [ ] Create a script (e.g., scripts/validate-docs-coverage.sh) that checks all commands have entries in docs/src/commands/
• [ ] Document any missing command pages in docs/src/commands/ (e.g., create docs/src/commands/<missing>.md if gaps exist)
• [ ] Add a GitHub Actions workflow step to .github/workflows/test.yml to run the validation script on PRs

Add unit tests and documentation for serde/TOML configuration parsing in cargo-toml-configuration.md

The repo uses toml, serde, serde_json, and serde_ignored for parsing Cargo.toml and Wasm-pack configuration, with docs/src/cargo-toml-configuration.md documenting the feature. However, there's likely no dedicated test suite for edge cases in configuration parsing (malformed TOML, missing required fields, version constraints, etc.). A contributor could add targeted unit tests and expand documentation with examples of common configuration mistakes.

• [ ] Identify the main configuration parsing code (likely in src/ modules handling Cargo.toml and Wasm-pack config)
• [ ] Add tests/unit/config_parsing.rs with cases for: valid configs, missing fields, type mismatches, deprecated fields, semver version constraints
• [ ] Expand docs/src/cargo-toml-configuration.md with a 'Common Mistakes' or 'Troubleshooting' section with examples
• [ ] Test interaction between serde_ignored and custom validation logic to ensure informative error messages

• Add integration tests for the 'pack' and 'publish' commands in tests/ similar to existing build/test command tests (currently minimal coverage visible)
• Expand docs/src/commands/index.md with a quick-reference table showing command options and output artifacts for all five commands (new, build, test, pack, publish)
• Implement colored output support for the console crate (already imported as dependency) to improve CLI UX when RUST_LOG output is displayed alongside command results

The wasm-pack project demonstrates reasonable security practices with proper licensing and documentation. However, there are notable concerns: (1) The use of binary-install for downloading and executing external binaries without visible cryptographic verification is a significant supply chain risk. (2) Dependencies like ureq and serde require careful usage review for SSRF and deserialization attacks. (3) The installer scripts require enhanced security measures. (4) Several dependencies are not on the latest versions and should be audited. The project would benefit from implementing automated security scanning (cargo audit in CI/CD), cryptographic verification for all external artifacts, and comprehensive security testing of the installer chain.

• Medium · Outdated Dependencies with Known Vulnerabilities — Cargo.toml. Several dependencies have older versions that may contain known security vulnerabilities. Specifically: anyhow 1.0.100, binary-install 0.4.1, clap 4.2.5, ureq 2.12.1, and others should be audited against CVE databases. The dependency 'binary-install' is particularly concerning as it downloads and executes binaries. Fix: Run 'cargo audit' to identify known vulnerabilities. Update all dependencies to their latest secure versions. Pay special attention to binary-install and ureq which handle external resources.
• High · Insecure Binary Installation Dependency — Cargo.toml - dependency: binary-install. The 'binary-install' crate (v0.4.1) is used for downloading and executing precompiled binaries. This presents significant security risks including: Man-in-the-Middle (MITM) attacks, supply chain attacks, and arbitrary code execution. The crate may not properly validate downloaded binaries or use secure transport. Fix: Audit the binary-install implementation for proper HTTPS validation, signature verification, and checksum validation. Consider implementing Code signing verification for downloaded binaries. Alternatively, evaluate alternatives or implement custom secure binary handling with cryptographic verification.
• Medium · Unvalidated External URL Requests — Cargo.toml - dependency: ureq. The 'ureq' dependency (v2.12.1) with 'socks-proxy' feature is used for HTTP requests. Without explicit code review, there's a risk of: Server-Side Request Forgery (SSRF), insecure deserialization, or insufficient TLS validation when handling external repositories or downloads. Fix: Review all usages of ureq for proper TLS/SSL validation, certificate pinning where applicable, and URL sanitization. Implement allowlist validation for any external URLs. Use secure defaults and validate all HTTP responses.
• Low · Missing Security Headers in Documentation — docs/ directory - missing security configuration. Documentation site (docs/ directory) serves HTML, CSS, and JavaScript assets. Without explicit security headers configuration visible in the repository, potential XSS vulnerabilities could exist. Fix: Implement security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options) in the documentation hosting configuration. This is likely handled by GitHub Pages or a separate web server.
• Low · Installer Script Without Signature Verification — docs/_installer/init.sh, docs/_installer/install.js. The installer script at 'docs/_installer/init.sh' downloads and executes code. If not properly secured, this could be a vector for supply chain attacks or MITM attacks. Fix: Implement cryptographic signature verification for downloaded scripts. Use HTTPS with certificate pinning. Consider providing checksums for verification. Document security considerations in installation instructions.
• Medium · Potential Deserialization Risks — Cargo.toml - dependencies: serde, serde_json, toml. The codebase uses serde/serde_json for parsing external data (Cargo.toml, package.json configs). Without proper validation, malicious manifests could cause issues. Fix: Implement strict schema validation for all deserialized data. Use serde's #[serde(deny_unknown_fields)] attribute. Validate all user-provided configuration files before processing.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.