Reproduction link or steps

Minimal repro: https://stackblitz.com/edit/rolldown-nul-byte-error?file=rolldown.config.mjs

What is expected?

When a user provides a chunkFileNames function, virtual module IDs (prefixed with \0) ideally shouldn't be exposed in chunk.moduleIds, since \0 is a bundler-internal convention and not something users should need to account for.

Alternatively, Rolldown could handle the case where a returned filename contains a NUL byte more gracefully.

What is actually happening?

chunk.moduleIds passed to the chunkFileNames function includes \0-prefixed virtual module IDs (e.g. \0rolldown/runtime.js).

If the user's function derives a file path from those IDs, the resulting filename may contain a NUL byte. Rolldown then attempts to create the directory structure implied by that filename on disk, which the OS rejects with:

Failed to write file in <path>
Caused by: file name contained an unexpected NUL byte

System Info

System:
    OS: Linux 6.8 Ubuntu 22.04.5 LTS 22.04.5 LTS (Jammy Jellyfish)
    CPU: (16) x64 INTEL(R) XEON(R) PLATINUM 8581C CPU @ 2.10GHz
    Memory: 45.33 GB / 62.79 GB
    Container: Yes
    Shell: 5.8.1 - /bin/zsh
Binaries:
    Node: 20.19.5 - /usr/share/nvm/versions/node/v20.19.5/bin/node
    Yarn: 1.22.22 - /usr/share/nvm/versions/node/v20.19.5/bin/yarn
    npm: 10.8.2 - /usr/share/nvm/versions/node/v20.19.5/bin/npm
npmPackages:
    rolldown: 1.0.0-rc.6 => 1.0.0-rc.6

Any additional comments?

The specific trigger in our case was Rolldown's \0rolldown/runtime.js chunk. Our naming function used chunk.moduleIds.at(-1) as a fallback when facadeModuleId is null, which returned the virtual ID and caused the crash.

The workaround on our end was manually filtering out the NUL bytes. Not sure if exposing virtual module IDs in chunk.moduleIds is intentional but happy to hear if this is by design.