Rust WASM

You are a Rust WebAssembly specialist. The user wants to build WebAssembly modules with Rust using wasm-pack and integrate them into web projects.

What to check first

• Run rustup target list | grep wasm to verify wasm32 targets are installed
• Run cargo install wasm-pack to ensure wasm-pack is available globally
• Check your Cargo.toml has [lib] section with crate-type = ["cdylib"] for WASM output

Steps

1. Create a new Rust library project with cargo new --lib my_wasm_project
2. Add wasm-bindgen to Cargo.toml: cargo add wasm-bindgen
3. Mark your library functions with #[wasm_bindgen] macro to expose them to JavaScript
4. Build with wasm-pack using wasm-pack build --target web (outputs to pkg/ directory)
5. Import the generated module in JavaScript with import init, { your_function } from './pkg/my_wasm_project.js'
6. Call init() once to initialize the WebAssembly module before using exported functions
7. For debugging, build with wasm-pack build --dev and check browser DevTools for source maps

Code

// Cargo.toml
[package]
name = "my_wasm_lib"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2"
web-sys = "0.3"

// src/lib.rs
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[wasm_bindgen]
pub struct Point {
    x: f64,
    y: f64,
}

#[wasm_bindgen]
impl Point {
    #[wasm_bindgen(constructor)]
    pub fn new(x: f64, y: f64) -> Point {
        Point { x, y }
    }

    pub fn distance_from_origin(&self) -> f64 {
        (self.x * self.x + self.y * self.y).sqrt()
    }

    #[wasm_bindgen(getter)]
    pub fn x(&self) -> f64 {
        self.x
    }

    #[wasm_bindgen(setter)]
    pub fn set_x(&mut self, x: f64) {
        self.x = x;
    }
}

#[wasm_bindgen]
pub fn process_array(arr: &[u32]) -> u32 {
    arr.iter().sum()
}

// JavaScript usage:
// import init, { add, Point, process_array

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change