What this prompt does
This prompt asks the AI to build a Rust library compiled to WebAssembly for [wasm_purpose], targeting [target_runtime]. It covers the full pipeline: project setup with wasm-pack and wasm-bindgen, exported functions with correct type mappings for String, Vec<u8>, and structs, generated JavaScript/TypeScript bindings, and a memory strategy of [memory_strategy] for moving data across the Wasm boundary. Error translation from Rust to JS exceptions, async support via wasm-bindgen-futures for [async_operations], and bundle-size optimization against a [target_size] budget round it out.
The structure works because the Rust-to-Wasm boundary is where most projects stumble, and this prompt makes every crossing explicit. By naming [memory_strategy] and the [target_size] target up front, you steer the model toward zero-copy patterns and aggressive wasm-opt/LTO/strip settings instead of a bloated default build. Benchmarks comparing Wasm against pure JavaScript on [benchmark_task] and integration with [js_framework] keep the result grounded in something you can ship as an npm package. Error translation matters here too: a Rust Result that panics across the boundary produces a useless JS stack trace, so the prompt insists errors map to proper JS exceptions consumers can catch.
When to use it
- You want to push compute-heavy work — parsing, hashing, image processing — off the JS thread without reimplementing it slowly in JavaScript.
- You are targeting both the browser and an edge runtime like Cloudflare Workers from one Rust codebase.
- You need a properly typed npm package so JS or
[js_framework]consumers get real TypeScript types. - Your bundle budget is tight and you want size optimization treated as a requirement, not an afterthought.
- You are unsure how to pass
String,Vec<u8>, or structs across the boundary efficiently. - You want a CI pipeline that builds, tests, and publishes the Wasm package automatically.
Example output
Expect a complete Rust crate with Cargo.toml, wasm-bindgen exports, generated JS/TS bindings, an npm package.json, and a demo HTML page that loads the module. You also get a size profile against the [target_size] budget, Wasm-vs-JS benchmark results for [benchmark_task], and a CI configuration for building and publishing.
Pro tips
- Make
[wasm_purpose]concrete — "Markdown parser" gives far sharper exports than "text utilities". - Set
[target_runtime]honestly; browser-plus-Workers code avoids APIs that only exist in one environment, and the model adjusts accordingly. - Push on
[memory_strategy]: "zero-copy where possible" with typed arrays avoids needless allocation, but verify the generated bindings actually skip copies. - Treat
[target_size]as a hard gate — if the first build blows past it, ask specifically for wasm-opt level, LTO, and strip settings. - Use the Wasm-vs-JS benchmark on
[benchmark_task]to confirm Wasm is actually faster for your workload; for tiny inputs the boundary overhead can erase the win. - If async via
[async_operations]returns awkward Promise types, ask for explicit wasm-bindgen-futures examples on the JS side.
