DioxusLabs/dioxus · error
failed to write js module
Error message
failed to write js module
What it means
After emitting the split modules, the CLI writes the JS loader glue `__wasm_split.js` into out_dir via `std::fs::write(...).expect("failed to write js module")`. Because `main.wasm` was written to the same directory moments earlier, failing here usually means the environment changed mid-run or this particular write was rejected: the disk filled up, the directory was deleted or locked by another process, or the filesystem errored.
Source
Thrown at packages/wasm-split/wasm-split-cli/src/main.rs:66
tracing::info!("Building split module");
let module = wasm_split_cli::Splitter::new(&original, &bindgened).unwrap();
let mut chunks = module.emit().unwrap();
// Write out the main module
tracing::info!(
"Writing main module to {}",
args.out_dir.join("main.wasm").display()
);
std::fs::write(args.out_dir.join("main.wasm"), &chunks.main.bytes).unwrap();
// Write the js module
std::fs::write(
args.out_dir.join("__wasm_split.js"),
emit_js(&chunks.chunks, &chunks.modules),
)
.expect("failed to write js module");
for (idx, chunk) in chunks.chunks.iter().enumerate() {
tracing::info!(
"Writing chunk {} to {}",
idx,
args.out_dir
.join(format!("chunk_{}_{}.wasm", idx, chunk.module_name))
.display()
);
std::fs::write(
args.out_dir
.join(format!("chunk_{}_{}.wasm", idx, chunk.module_name)),
&chunk.bytes,
)
.expect("failed to write chunk");
}
for (idx, module) in chunks.modules.iter_mut().enumerate() {View on GitHub (pinned to 393d190a80)
Solutions
- Check the OS error text accompanying the panic; if ENOSPC, free disk space (`df -h`) and re-run
- Make sure no other process (watch mode, parallel CI step) writes to or deletes out_dir while split runs - serialize the build steps
- Move out_dir onto a local filesystem instead of a network mount
- On Windows, exclude the build directory from antivirus scanning or pause the lock
Example fix
# before: split and e2e test race on the same dist dir, one write fails wasm-split-cli split app.wasm bg.wasm dist & run-e2e dist & # after: serialize the steps so split finishes first wasm-split-cli split app.wasm bg.wasm dist && run-e2e dist
Defensive patterns
Strategy: validation
Validate before calling
df -h . | awk 'NR==2 && $5+0 > 90 { print "disk nearly full"; exit 1 }'
flock dist.lock wasm-split-cli split app.wasm bg.wasm dist # serialize all writers of dist Try / catch
if ! wasm-split-cli split app.wasm bg.wasm dist; then echo "split failed mid-write (exit $?) - likely ENOSPC, a lock, or a concurrent writer" >&2; exit 1; fi
Prevention
- Keep exactly one writer per output directory; serialize split and downstream steps with a lock or && chaining
- Fail CI when disk usage crosses a threshold before the build, not after writes start failing
- Write outputs to local scratch space and copy artifacts afterwards, avoiding NFS/SMB out dirs
- Exclude build directories from antivirus scanning on Windows
When it happens
Trigger: Disk (or inode) exhaustion between the main.wasm write and the glue write; a concurrent build/watch process deleting or recreating out_dir while split is writing; antivirus or file-locking software quarantining the newly created .js file on Windows; out_dir on a flaky network mount (NFS/SMB) returning EIO.
Common situations: Parallel CI jobs or a `dx` watch process sharing one output directory; Docker builds hitting layer/inode limits; corporate endpoint protection locking freshly written files.
Related errors
- Failed to write rustc args to file
- failed to read input file
- failed to create output dir
- failed to write chunk
- failed to expand ifunc table
AI-assisted analysis of DioxusLabs/dioxus@393d190a80 (2026-08-16).
Data as JSON: /api/errors/196d25fcd1e88c4e.
Report an issue: GitHub.