Setting Up wasm-pack

21 min read

The toolchain that turns a Rust crate into an npm-installable, browser-ready WebAssembly package. This is the build step that sits between cargo and your bundler.

Quick Overview

wasm-pack is the build orchestrator for Rust-to-WebAssembly (WASM) projects: it compiles your crate to the wasm32-unknown-unknown target, runs wasm-bindgen to generate the JavaScript/TypeScript glue, optimizes the binary with wasm-opt, and emits a ready-to-publish package directory. For a TypeScript/JavaScript developer, think of it as the equivalent of tsc + a bundler plugin + npm pack, except the input is Rust and the output is a .wasm file with .js and .d.ts files wrapped around it. The single most important configuration decision is the crate’s crate-type and the build target (web, bundler, or nodejs), which together determine the shape of the generated JavaScript glue.

Note: This file covers project setup, the cdylib crate type, and choosing a build target. Actually writing and calling exported functions is covered in first-wasm.md and rust-from-js.md. For what WebAssembly is and when it beats plain JavaScript, start with wasm-intro.md.

TypeScript/JavaScript Example

In the JavaScript world, shipping a library to a browser or to npm is a familiar pipeline: write TypeScript, compile it with tsc (which emits .js plus .d.ts type declarations), and let a bundler or npm publish package it. The runtime (V8) is already present, and the toolchain is implicit in your package.json scripts.

1
# Scaffold a TypeScript library
2
mkdir greeter && cd greeter
3
npm init -y
4
npm install --save-dev typescript
5
npx tsc --init

1
{
2
  "name": "greeter",
3
  "version": "0.1.0",
4
  "type": "module",
5
  "main": "dist/index.js",
6
  "types": "dist/index.d.ts",
7
  "files": ["dist"],
8
  "scripts": {
9
    "build": "tsc"
10
  },
11
  "devDependencies": {
12
    "typescript": "^5.6.0"
13
  }
14
}

1
export function greet(name: string): string {
2
  return `Hello, ${name}! This greeting came from TypeScript.`;
3
}
4

5
// A CPU-bound function: count primes below `limit`.
6
export function countPrimes(limit: number): number {
7
  let count = 0;
8
  for (let n = 2; n < limit; n++) {
9
    let isPrime = true;
10
    for (let d = 2; d * d <= n; d++) {
11
      if (n % d === 0) {
12
        isPrime = false;
13
        break;
14
      }
15
    }
16
    if (isPrime) count++;
17
  }
18
  return count;
19
}

1
npm run build
2
# tsc emits dist/index.js and dist/index.d.ts

Two things matter for the comparison ahead. First, tsc produces a .js file and a matching .d.ts declaration file — the artifact split that lets consumers get both runnable code and types. Second, the output target (CommonJS vs ES modules, which browsers/bundlers it suits) is controlled by tsconfig.json. wasm-pack mirrors both of these ideas, but the runnable artifact is a .wasm binary with a generated .js loader wrapped around it, and the “output target” is chosen with a --target flag instead of a config file.

Rust Equivalent

First, install the tooling. You need the Rust toolchain (which you already have from Section 01), the wasm32-unknown-unknown compilation target, and the wasm-pack CLI:

1
# Add the WebAssembly compilation target to your toolchain
2
rustup target add wasm32-unknown-unknown
3

4
# Install the wasm-pack CLI (one-time, global)
5
cargo install wasm-pack

Note: wasm-pack will also auto-download a matching wasm-bindgen CLI and wasm-opt on first build, so you do not install those separately. The version used while writing this guide was wasm-pack 0.13.1 with wasm-bindgen 0.2.122; run wasm-pack --version and check the releases page for newer versions, since the CLI evolves.

Now scaffold the crate. A WASM project is a library crate, not a binary, so use --lib:

1
cargo new --lib greeter
2
cd greeter
3
cargo add wasm-bindgen

The crucial edit is to Cargo.toml. You must declare the crate’s crate-type as cdylib so the compiler emits a self-contained dynamic library — the format wasm-bindgen needs:

1
[package]
2
name = "greeter"
3
version = "0.1.0"
4
edition = "2024"
5

6
[lib]
7
crate-type = ["cdylib", "rlib"]
8

9
[dependencies]
10
wasm-bindgen = "0.2.122"

The library source exports functions with #[wasm_bindgen]:

1
use wasm_bindgen::prelude::*;
2

3
/// Greets a user by name. Exported to JavaScript as `greet`.
4
#[wasm_bindgen]
5
pub fn greet(name: &str) -> String {
6
    format!("Hello, {name}! This greeting came from Rust + WebAssembly.")
7
}
8

9
/// CPU-bound work: count the primes below `limit`. The kind of tight numeric
10
/// loop where compiled WebAssembly comfortably beats interpreted JavaScript.
11
#[wasm_bindgen]
12
pub fn count_primes(limit: u32) -> u32 {
13
    let mut count = 0;
14
    for n in 2..limit {
15
        let mut is_prime = true;
16
        let mut d = 2;
17
        while d * d <= n {
18
            if n % d == 0 {
19
                is_prime = false;
20
                break;
21
            }
22
            d += 1;
23
        }
24
        if is_prime {
25
            count += 1;
26
        }
27
    }
28
    count
29
}

Build it for the browser:

1
wasm-pack build --target web

The real output (versions and timings will differ on your machine):

1
[INFO]:  Checking for the Wasm target...
2
[INFO]:  Compiling to Wasm...
3
    Finished `release` profile [optimized] target(s) in 1.74s
4
[INFO]:  Installing wasm-bindgen...
5
[INFO]: Optimizing wasm binaries with `wasm-opt`...
6
[INFO]: Optional fields missing from Cargo.toml: 'description', 'repository', and 'license'. These are not necessary, but recommended
7
[INFO]:   Done in 5.89s
8
[INFO]:   Your wasm pkg is ready to publish at /path/to/greeter/pkg.

This produces a pkg/ directory — the analog of the dist/ that tsc produced above:

1
pkg/
2
├── greeter_bg.wasm        # the compiled WebAssembly binary (wasm-opt'd)
3
├── greeter_bg.wasm.d.ts   # TypeScript types for the raw wasm exports
4
├── greeter.js             # generated JS loader/glue (the part you import)
5
├── greeter.d.ts           # TypeScript declarations for the JS glue
6
├── package.json           # generated; makes pkg/ npm-installable
7
└── .gitignore

The greeter.d.ts is generated by wasm-bindgen from your Rust signatures — your greet(name: &str) -> String becomes a TypeScript declaration automatically:

1
// pkg/greeter.d.ts (excerpt, generated)
2
/**
3
 * Greets a user by name. Exported to JavaScript as `greet`.
4
 */
5
export function greet(name: string): string;
6

7
/**
8
 * CPU-bound work: count the primes below `limit`. ...
9
 */
10
export function count_primes(limit: number): number;

Tip: Your Rust doc comments (///) flow straight into the generated .d.ts as JSDoc. Documenting the Rust function documents the TypeScript API for free.

Detailed Explanation

Why a `cdylib` crate type?

By default, a Rust library crate compiles to an rlib — Rust’s own static library format, only understood by the Rust compiler and only useful when linked into another Rust crate. WebAssembly modules are loaded by a JavaScript host (the browser or Node), not by rustc, so you need a different output format.

cdylib stands for “C-compatible dynamic library.” It tells the compiler to produce a standalone, self-contained module with a stable, language-agnostic export surface — exactly what a .wasm module is. On the wasm32-unknown-unknown target, cdylib produces the .wasm file that wasm-bindgen then post-processes.

The list ["cdylib", "rlib"] asks for both outputs:

cdylib — the WASM artifact that ships to JavaScript.
rlib — the normal Rust library output, which lets you keep running cargo test on the host and depend on the crate from other Rust crates.

You can write just crate-type = ["cdylib"], but then cargo test (which needs an rlib) will not work for this crate. Including rlib costs nothing and keeps your tests runnable on the host, so it is the standard recommendation.

Note: This is conceptually the same idea as choosing "module": "ESNext" vs "CommonJS" in tsconfig.json — you are selecting an output format for a different consumer. Here the consumer is a WASM host instead of a JavaScript runtime.

What `wasm-pack build` actually does

The wasm-pack build command is a pipeline, and each [INFO] line above is one stage:

Checking for the Wasm target — confirms wasm32-unknown-unknown is installed (the rustup target add step).
Compiling to Wasm — runs cargo build --release --target wasm32-unknown-unknown under the hood. The “release” profile is the default for wasm-pack build; that is why the binary is optimized.
Installing wasm-bindgen — downloads (once) the wasm-bindgen CLI matching the wasm-bindgen crate version in your Cargo.toml, then runs it on the raw .wasm to generate the JS/TS glue.
Optimizing wasm binaries with wasm-opt — shrinks and speeds up the binary using the Binaryen optimizer.
Writing the package — emits the pkg/ directory with a generated package.json.

The raw cargo build step on its own would give you only target/wasm32-unknown-unknown/release/greeter.wasm — a binary with no JavaScript wrapper and a hard-to-call ABI. wasm-pack exists to wrap that into something a bundler or npm can consume.

The two-file artifact: `.wasm` + `.js` glue

Unlike a tsc build where dist/index.js is your runnable code, a WASM package always has two layers:

greeter_bg.wasm — the compiled machine-ish bytecode. It cannot be imported directly with full ergonomics: strings, structs, and Vecs do not cross the JS↔WASM boundary natively (WASM only speaks numbers and linear memory).
greeter.js — the glue that wasm-bindgen generates. It allocates memory, copies your JS string into the WASM module’s linear memory, calls the raw export, reads the result back out, and decodes it into a JS string. The _bg suffix is short for bindgen; it marks the lower-level, wasm-facing module that the higher-level greeter.js wraps.

This is why even a one-line greet function needs the glue: the boundary marshalling is non-trivial, and wasm-bindgen writes it for you. The mechanics of that boundary are the subject of wasm-bindgen.md.

The generated `package.json`

wasm-pack writes a package.json into pkg/ so the directory is immediately npm install-able (locally via a path, or publishable to a registry). For the web target it looks like this:

1
{
2
  "name": "greeter",
3
  "type": "module",
4
  "version": "0.1.0",
5
  "files": ["greeter_bg.wasm", "greeter.js", "greeter.d.ts"],
6
  "main": "greeter.js",
7
  "types": "greeter.d.ts",
8
  "sideEffects": ["./snippets/*"]
9
}

name and version are copied from your Cargo.toml. main and types point at the generated JS and declarations — exactly like the hand-written package.json in the TypeScript example, but produced for you.

Key Differences

Concern	TypeScript (`tsc` + bundler)	Rust (`wasm-pack`)
Source	`.ts` files	a Rust library crate (`--lib`)
Output unit	`.js` (+ `.d.ts`)	`.wasm` + generated `.js` glue (+ `.d.ts`)
Crate/module config	`tsconfig.json` `module`/`target`	`Cargo.toml` `crate-type` + `wasm-pack --target`
Runtime present?	yes (V8 ships with Node/browser)	the WASM module must be fetched and instantiated
Type declarations	emitted by `tsc`	emitted by `wasm-bindgen` from Rust signatures
Package metadata	hand-written `package.json`	generated into `pkg/package.json`
Optimization	bundler minifier (terser/esbuild)	`wasm-opt` (built into the build)

The biggest conceptual shift: in TypeScript the output format (ESM vs CJS) is a compiler setting; in Rust the crate type (cdylib) is a Cargo setting, while the JavaScript flavor (ESM for the web, CommonJS for Node, bundler-friendly imports) is the separate wasm-pack --target flag described next.

Note: Unlike TypeScript, where types are erased and the runtime values are plain JavaScript, the .wasm binary is genuinely separate compiled code with its own linear memory. The .d.ts describes a foreign module, not the same code with annotations stripped.

Choosing a Build Target

The --target flag decides what kind of JavaScript glue wasm-bindgen writes and therefore where the package can be loaded. The three you will use in practice are web, bundler, and nodejs. The crate, the Rust code, and the .wasm binary are identical across all three — only the glue and package.json change.

`--target web`

1
wasm-pack build --target web

Generates ES-module glue that loads the .wasm with the browser’s native fetch + WebAssembly.instantiateStreaming. The default export is an async init() function you call before using any exports — there is no bundler required, so you can <script type="module"> it straight from a static page. This is the right choice for a plain HTML page or a framework that does not pre-process .wasm imports.

The generated package.json sets "type": "module" and lists greeter.js as main:

1
{
2
  "name": "greeter",
3
  "type": "module",
4
  "version": "0.1.0",
5
  "files": ["greeter_bg.wasm", "greeter.js", "greeter.d.ts"],
6
  "main": "greeter.js",
7
  "types": "greeter.d.ts",
8
  "sideEffects": ["./snippets/*"]
9
}

`--target bundler`

1
wasm-pack build --target bundler

This is the default target if you omit --target. It generates ESM glue that uses an import of the .wasm file directly, relying on a bundler (Vite, webpack, Rollup) to resolve and serve the binary. It produces an extra greeter_bg.js file (the wasm-facing glue) and re-exports through greeter.js. There is no init() call to make — the bundler wires up instantiation. Use this when the package is consumed inside a webpack/Vite app.

Notice the differences in the generated package.json: an added greeter_bg.js in files, and ./greeter.js listed in sideEffects:

1
{
2
  "name": "greeter",
3
  "type": "module",
4
  "version": "0.1.0",
5
  "files": ["greeter_bg.wasm", "greeter.js", "greeter_bg.js", "greeter.d.ts"],
6
  "main": "greeter.js",
7
  "types": "greeter.d.ts",
8
  "sideEffects": ["./greeter.js", "./snippets/*"]
9
}

`--target nodejs`

1
wasm-pack build --target nodejs

Generates CommonJS glue. The loader reads the .wasm file synchronously from disk with require('fs').readFileSync and instantiates it eagerly, so there is no async init() — you require() the package and call functions immediately. Use this for a Node.js script, a CLI, or a server-side dependency. The package.json notably does not set "type": "module":

1
{
2
  "name": "greeter",
3
  "version": "0.1.0",
4
  "files": ["greeter_bg.wasm", "greeter.js", "greeter.d.ts"],
5
  "main": "greeter.js",
6
  "types": "greeter.d.ts"
7
}

Targets at a glance

`--target`	Module system	How `.wasm` loads	`init()` needed?	Use when
`web`	ESM	`fetch` + streaming instantiate	yes (async default export)	static HTML page, no bundler
`bundler` (default)	ESM	bundler resolves the `import`	no (bundler wires it)	inside Vite/webpack/Rollup
`nodejs`	CommonJS	`fs.readFileSync` (sync)	no (eager)	Node script, CLI, server
`no-modules`	global `wasm_bindgen`	manual	yes	legacy `<script>` (no `type="module"`)
`deno`	ESM	URL fetch	yes	Deno runtime

Tip: Build into different --out-dir directories when you need more than one target from the same crate, e.g. wasm-pack build --target web --out-dir pkg-web and wasm-pack build --target nodejs --out-dir pkg-node. The default --out-dir is pkg.

Common Pitfalls

Forgetting `crate-type = ["cdylib"]`

This is the number-one setup mistake. If your Cargo.toml has no [lib] crate-type, wasm-pack stops immediately with a precise error. Running the build on a crate that lacks it produces exactly this:

1
Error: crate-type must be cdylib to compile to wasm32-unknown-unknown. Add the following to your Cargo.toml file:
2

3
[lib]
4
crate-type = ["cdylib", "rlib"]

The fix is in the message: add the [lib] section. (wasm-pack is unusually helpful here — it tells you the exact lines to paste.)

Scaffolding a binary instead of a library

cargo new greeter (without --lib) creates a binary crate with src/main.rs and a fn main(). WASM modules built with wasm-pack are libraries — there is no main entry point, you export functions. Use cargo new --lib greeter, and put your code in src/lib.rs.

Missing the `wasm32-unknown-unknown` target

If you skipped rustup target add wasm32-unknown-unknown, wasm-pack will detect it and offer to install it, but a raw cargo build --target wasm32-unknown-unknown would fail with error[E0463]: can't find crate for 'std' / a note that the target may not be installed. Install the target once per toolchain.

Reaching for the wrong target

A package built with --target nodejs (CommonJS, synchronous fs load) will not work in a browser, and a --target web package’s async init() flow will confuse a require()-based Node script. The Rust code is identical; the glue is not interchangeable. Decide where the package runs before you build, and rebuild with the right --target if you change your mind.

Expecting to `import` the `.wasm` directly

You cannot meaningfully import greet from './greeter_bg.wasm' and get a working String-returning function — the raw module only exports numeric, memory-pointer-based functions. Always import from the generated greeter.js, never from the bare .wasm. The glue is the public API.

Assuming `cargo install wasm-pack` needs extra tooling

Some older guides tell you to install wasm-bindgen-cli and wasm-opt separately. You do not — modern wasm-pack downloads matching versions of both on first build and caches them. Just install wasm-pack itself.

Best Practices

Always include rlib alongside cdylib (crate-type = ["cdylib", "rlib"]) so cargo test and host-side use keep working. Test your pure logic on the host where it is fast; reserve browser testing for the boundary.
Pick the target by destination, not by habit. web for a static page, bundler (the default) inside Vite/webpack, nodejs for a server or CLI. Document the chosen target in your README so consumers know how to import it.
Build into named --out-dirs when you publish multiple targets (pkg-web, pkg-node) instead of overwriting pkg.
Use wasm-pack build --release for shipping (it is the default) and --dev only for fast local iteration; the dev profile skips optimizations and produces a much larger, slower binary.
Add the optional description, repository, and license fields to Cargo.toml if you intend to publish — wasm-pack reminds you, and they flow into the generated package.json.
Keep wasm-pack, the wasm-bindgen crate, and the wasm-bindgen CLI in sync. wasm-pack handles this automatically, but if you ever invoke wasm-bindgen by hand, a version mismatch between the crate and the CLI is a classic source of cryptic glue errors. Let wasm-pack own that for you.

Real-World Example

A common production setup is a small Rust crate that does one CPU-heavy job, built for the browser via Vite. Here is the full, build-verified crate plus the loader page for the web target.

1
[package]
2
name = "greeter"
3
version = "0.1.0"
4
edition = "2024"
5
description = "A tiny Rust→WASM greeting and prime-counting demo"
6
license = "MIT"
7

8
[lib]
9
crate-type = ["cdylib", "rlib"]
10

11
[dependencies]
12
wasm-bindgen = "0.2.122"

1
use wasm_bindgen::prelude::*;
2

3
/// Greets a user by name. Exported to JavaScript as `greet`.
4
#[wasm_bindgen]
5
pub fn greet(name: &str) -> String {
6
    format!("Hello, {name}! This greeting came from Rust + WebAssembly.")
7
}
8

9
/// CPU-bound work: count the primes below `limit`.
10
#[wasm_bindgen]
11
pub fn count_primes(limit: u32) -> u32 {
12
    let mut count = 0;
13
    for n in 2..limit {
14
        let mut is_prime = true;
15
        let mut d = 2;
16
        while d * d <= n {
17
            if n % d == 0 {
18
                is_prime = false;
19
                break;
20
            }
21
            d += 1;
22
        }
23
        if is_prime {
24
            count += 1;
25
        }
26
    }
27
    count
28
}
29

30
// Pure-logic tests still run on the host, thanks to the `rlib` crate type.
31
#[cfg(test)]
32
mod tests {
33
    use super::*;
34

35
    #[test]
36
    fn counts_primes_below_100() {
37
        assert_eq!(count_primes(100), 25);
38
    }
39
}

Build it for a static page:

1
wasm-pack build --target web --out-dir pkg

Then load and use it from an HTML page — no bundler required for the web target:

1
<!doctype html>
2
<html lang="en">
3
  <head>
4
    <meta charset="utf-8" />
5
    <title>Rust + WASM</title>
6
  </head>
7
  <body>
8
    <pre id="out"></pre>
9
    <script type="module">
10
      import init, { greet, count_primes } from "./pkg/greeter.js";
11

12
      // The `web` target's default export is an async init() that
13
      // fetches and instantiates the .wasm before any export is callable.
14
      await init();
15

16
      const out = document.getElementById("out");
17
      out.textContent =
18
        greet("Ada") + "\n" + "primes below 100: " + count_primes(100);
19
    </script>
20
  </body>
21
</html>

Note: Because the web target loads the .wasm with fetch, the page must be served over HTTP, not opened as a file:// URL — browsers block fetch of local files. Any static server works; serving is covered in deployment.md.

For a server-side consumer, the same crate built with --target nodejs is usable directly from Node. Building with wasm-pack build --target nodejs --out-dir pkg-node and running this script prints real output:

1
import { createRequire } from "node:module";
2
const require = createRequire(import.meta.url);
3
const greeter = require("./pkg-node/greeter.js"); // CommonJS glue, eager-loaded
4

5
console.log(greeter.greet("Ada"));
6
console.log("primes below 100:", greeter.count_primes(100));

1
Hello, Ada! This greeting came from Rust + WebAssembly.
2
primes below 100: 25

The same Rust source, two different targets, two different ways to load it — and the count_primes(100) === 25 result is identical, computed inside the WASM module both times.

Exercises

Exercise 1: Scaffold and build for the web

Difficulty: Beginner

Objective: Produce a working pkg/ directory from scratch.

Instructions:

Install the WASM target and wasm-pack if you have not (rustup target add wasm32-unknown-unknown, cargo install wasm-pack).
Run cargo new --lib texttools and cd into it.
Add wasm-bindgen, set the [lib] crate-type to ["cdylib", "rlib"], and export a function shout(text: &str) -> String that returns the text uppercased.
Run wasm-pack build --target web and confirm pkg/texttools.js, pkg/texttools.d.ts, and pkg/texttools_bg.wasm all exist.

Solution

1
rustup target add wasm32-unknown-unknown   # one-time
2
cargo install wasm-pack                    # one-time
3
cargo new --lib texttools
4
cd texttools
5
cargo add wasm-bindgen

1
[package]
2
name = "texttools"
3
version = "0.1.0"
4
edition = "2024"
5

6
[lib]
7
crate-type = ["cdylib", "rlib"]
8

9
[dependencies]
10
wasm-bindgen = "0.2.122"

1
use wasm_bindgen::prelude::*;
2

3
/// Returns `text` in uppercase. Exported to JS as `shout`.
4
#[wasm_bindgen]
5
pub fn shout(text: &str) -> String {
6
    text.to_uppercase()
7
}

1
wasm-pack build --target web
2
ls pkg/
3
# texttools.js  texttools.d.ts  texttools_bg.wasm  texttools_bg.wasm.d.ts  package.json

The generated pkg/texttools.d.ts will contain export function shout(text: string): string; — your Rust signature, translated.

Exercise 2: Compare two targets

Difficulty: Intermediate

Objective: See how the --target flag changes the generated package without changing the Rust.

Instructions:

Using the texttools crate from Exercise 1, build it twice into separate directories: once for web (--out-dir pkg-web) and once for nodejs (--out-dir pkg-node).
Open both generated package.json files and identify two concrete differences.
Explain in one sentence why the nodejs build does not need an async init() call.

Solution

1
wasm-pack build --target web    --out-dir pkg-web
2
wasm-pack build --target nodejs --out-dir pkg-node

Two differences in the generated package.json:

The web build sets "type": "module" (ES modules); the nodejs build omits it, so it is treated as CommonJS.
The web build lists "sideEffects": ["./snippets/*"]; the nodejs build has no sideEffects field.

The nodejs glue loads the .wasm synchronously from disk with require('fs').readFileSync and instantiates it eagerly at require() time, so the exports are ready immediately — there is no asynchronous fetch to await, hence no init(). The web glue must fetch the binary over the network, which is inherently asynchronous, so it exposes an async init() you await first.

Exercise 3: Diagnose a missing crate type

Difficulty: Intermediate

Objective: Recognize and fix the most common wasm-pack setup error.

Instructions:

Create cargo new --lib brokenpkg, add wasm-bindgen, and export a trivial #[wasm_bindgen] pub fn ping() -> i32 { 1 }. Do not add a [lib] crate-type.
Run wasm-pack build --target web and read the error.
Apply the fix the error suggests and rebuild successfully.

Solution

Step 2 fails with this exact message (real output from wasm-pack 0.13.1):

1
Error: crate-type must be cdylib to compile to wasm32-unknown-unknown. Add the following to your Cargo.toml file:
2

3
[lib]
4
crate-type = ["cdylib", "rlib"]

The fix is to add the [lib] section the error prints, so Cargo.toml becomes:

1
[package]
2
name = "brokenpkg"
3
version = "0.1.0"
4
edition = "2024"
5

6
[lib]
7
crate-type = ["cdylib", "rlib"]
8

9
[dependencies]
10
wasm-bindgen = "0.2.122"

1
use wasm_bindgen::prelude::*;
2

3
#[wasm_bindgen]
4
pub fn ping() -> i32 {
5
    1
6
}

Rebuilding now succeeds and writes pkg/:

1
wasm-pack build --target web
2
# [INFO]:   Done in N.NNs
3
# [INFO]:   Your wasm pkg is ready to publish at .../brokenpkg/pkg.

Setting Up wasm-pack

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Why a `cdylib` crate type?

What `wasm-pack build` actually does

The two-file artifact: `.wasm` + `.js` glue

The generated `package.json`

Key Differences

Choosing a Build Target

`--target web`

`--target bundler`

`--target nodejs`

Targets at a glance

Common Pitfalls

Forgetting `crate-type = ["cdylib"]`

Scaffolding a binary instead of a library

Missing the `wasm32-unknown-unknown` target

Reaching for the wrong target

Expecting to `import` the `.wasm` directly

Assuming `cargo install wasm-pack` needs extra tooling

Best Practices

Real-World Example

Further Reading

Official Documentation

Exercises

Exercise 1: Scaffold and build for the web

Exercise 2: Compare two targets

Exercise 3: Diagnose a missing crate type

Setting Up wasm-pack

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Why a cdylib crate type?

What wasm-pack build actually does

The two-file artifact: .wasm + .js glue

The generated package.json

Key Differences

Choosing a Build Target

--target web

--target bundler

--target nodejs

Targets at a glance

Common Pitfalls

Forgetting crate-type = ["cdylib"]

Scaffolding a binary instead of a library

Missing the wasm32-unknown-unknown target

Reaching for the wrong target

Expecting to import the .wasm directly

Assuming cargo install wasm-pack needs extra tooling

Best Practices

Real-World Example

Further Reading

Official Documentation

Related Sections

Exercises

Exercise 1: Scaffold and build for the web

Exercise 2: Compare two targets

Exercise 3: Diagnose a missing crate type

Why a `cdylib` crate type?

What `wasm-pack build` actually does

The two-file artifact: `.wasm` + `.js` glue

The generated `package.json`

`--target web`

`--target bundler`

`--target nodejs`

Forgetting `crate-type = ["cdylib"]`

Missing the `wasm32-unknown-unknown` target

Expecting to `import` the `.wasm` directly

Assuming `cargo install wasm-pack` needs extra tooling