Registry /
workflow / windmill-parser-wasm-rust
Install & Compatibility
Where this runs
tested against v? · npm install
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
muslnode 18–226 runs
build_error
glibcnode 18–226 runs
build_error
Code
Verified usage
Verified import paths — ran on the pinned version, not inferred.
init
✓ import init, { parseCode } from 'windmill-parser-wasm-rust';
✗ const { init, parseCode } = require('windmill-parser-wasm-rust');
WASM modules compiled with `wasm-pack` (which this package utilizes) typically export an `init` function that must be called once to load the WebAssembly module before any other exported functions can be used. This package is ESM-only.
parseCode
✓ import init, { parseCode } from 'windmill-parser-wasm-rust';
✗ import { parseCode } from 'windmill-parser-wasm-rust/pkg'; // Incorrect subpath after wasm-pack bundling
The primary parsing function, assumed to be `parseCode` (actual name may vary without documented API), is exposed as a named export after `init` has been called. The package typically exports directly from the root, not a `pkg` subfolder for the npm package.
* as wasm
✓ import * as wasm from 'windmill-parser-wasm-rust';
await wasm.default(); // Call default init function
const result = wasm.parseCode('...');
✗ import wasm from 'windmill-parser-wasm-rust'; // Default import might not expose all members directly
For `wasm-pack` generated packages, `import * as wasm` is a common pattern. The `init` function might be exported as `default` or a named export, so `wasm.default()` or `wasm.init()` should be checked. If `init` is the default export, it's called as `wasm.default()` (or `await init()` if imported directly).
This quickstart demonstrates how to initialize the WebAssembly module and use a hypothetical `parseCode` function to process a script string.
import init, { parseCode } from 'windmill-parser-wasm-rust';
async function runParser() {
try {
// Initialize the WebAssembly module
await init();
console.log('WebAssembly module initialized successfully.');
const scriptContent = `
function hello(name: string) {
console.log("Hello, " + name);
return { message: "Processed" };
}
`;
// Assume parseCode takes a string and returns a JSON string or object
const parseResult = parseCode(scriptContent);
console.log('Parsed script content:', parseResult);
// Example: If parseResult is a string, parse it
if (typeof parseResult === 'string') {
try {
const parsedData = JSON.parse(parseResult);
console.log('Parsed data (JSON):', parsedData);
} catch (jsonError) {
console.error('Failed to parse JSON result:', jsonError);
}
} else {
console.log('Parsed data (object):', parseResult);
}
} catch (error) {
console.error('Error loading or using WASM parser:', error);
}
}
runParser();
Debug
Known issues
gotchaFor certain workloads, particularly those involving extensive string manipulation and frequent data exchange across the JavaScript-WebAssembly boundary, a Rust WASM parser might be less performant than a pure TypeScript implementation. This is due to overheads like string copying and serialization/deserialization at the WASM-JS interface, which can negate Rust's raw compute speed benefits for I/O-bound tasks. Consider profiling specific use cases.fixProfile your application with both Rust WASM and equivalent TypeScript implementations. Optimize data transfer between JS and WASM by minimizing string copies and using numerical representations where possible. Consider whether the performance-critical part of your logic genuinely benefits from WASM or if a direct JS/TS implementation is more efficient for that specific workload.
affects: >=1.0.0
breakingRust WASM targets are deprecating the `--allow-undefined` flag in `wasm-ld`, with the change slated for Rust 1.96 (May 2026). This change could lead to linker errors for existing Rust WASM projects that implicitly relied on this flag for undefined symbols, potentially producing broken WebAssembly modules instead of clear compilation errors.fixEnsure all symbols are correctly defined and linked in your Rust WASM project. Review your build process and dependencies to prevent undefined symbols from being imported into the final WebAssembly module. Update Rust toolchains and `wasm-bindgen-cli` to be compatible with the new linking behavior. Explicitly define all imports needed by the WASM module.
affects: >=1.96.0 (Rust compiler)
gotchaRust panics within a WebAssembly module do not propagate as standard JavaScript exceptions. Instead, they result in the WASM instance aborting, leading to an unresolved JavaScript Promise (a 'leaked' promise) if the Rust function was asynchronous. This can leave the system in an inconsistent state and make debugging difficult, as `catch` blocks in JavaScript will not be triggered as expected.fixImplement robust error handling within your Rust code to prevent panics from reaching the WASM boundary. Use `Result` for fallible operations. If a panic occurs, consider the WASM instance unsafe and discard/re-initialize it. Use `console_error_panic_hook` in Rust to log panics to the browser console for better visibility during development.
affects: >=1.0.0
gotchaInteracting with Rust WASM modules compiled with `wasm-bindgen` requires careful consideration of Rust's ownership and borrowing rules, which have no direct equivalent in JavaScript. Incorrect handling of Rust values across the JS boundary can lead to unexpected runtime behavior or memory leaks that are not caught by the Rust compiler.fixFamiliarize yourself with `wasm-bindgen`'s guidelines on ownership and lifetime management. Pay close attention to types passed across the boundary (e.g., `&str` vs. `String`, `&[T]` vs. `Vec<T>`). Ensure that Rust-managed memory is properly released or transferred to JavaScript's garbage collector when appropriate.
affects: >=1.0.0
Errors
Common errors & fixes
TypeError: Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../".
This error often indicates that an imported symbol in your WebAssembly module, such as `"env"` or `"wasi_snapshot_preview1"`, could not be resolved by the JavaScript environment, potentially due to an underlying undefined symbol in the Rust code that was allowed to compile.
fixEnsure all Rust code paths are correctly linking to necessary imports. Verify your `wasm-pack` build configuration and any `wasm-bindgen` related `extern "C"` blocks. For Node.js/Service Worker environments, specifically address `getrandom` or similar library fallbacks if they are causing `module.require` issues by providing web-compatible shims or configurations.
Uncaught (in promise) Error: module.require is not supported
This error occurs when `wasm-bindgen` generated JavaScript glue code (often related to libraries like `getrandom`) tries to use `module.require` in a Service Worker or browser environment where it's not available. This is typically a fallback meant for Node.js.
fixWhen building for the web, ensure `wasm-pack` is configured with `--target web`. If the issue persists, you might need to manually inspect the generated `wasm-bindgen` JS and provide a custom shim for `module.require` within your Service Worker setup, or configure the problematic dependency to avoid Node.js-specific fallbacks.
The future provided panics then the returned Promise will not resolve. Instead it will be a leaked promise.
This is a documented limitation of `wasm-bindgen` where an async Rust function that panics will cause the corresponding JavaScript Promise to never resolve, leading to a 'stuck' `await` call in JavaScript.
fixAs much as possible, prevent Rust panics by using `Result` for error handling and propogating errors explicitly. If panics cannot be avoided, consider the WASM instance compromised and re-initialize it after a panic to prevent inconsistent states. You can use `std::panic::set_hook` to log panic messages to the console for debugging.
Audit
Dependencies
No dependency data recorded yet.