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

  1. Check the OS error text accompanying the panic; if ENOSPC, free disk space (`df -h`) and re-run
  2. Make sure no other process (watch mode, parallel CI step) writes to or deletes out_dir while split runs - serialize the build steps
  3. Move out_dir onto a local filesystem instead of a network mount
  4. 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

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


AI-assisted analysis of DioxusLabs/dioxus@393d190a80 (2026-08-16). Data as JSON: /api/errors/196d25fcd1e88c4e. Report an issue: GitHub.