[Bug]: Chunk render cache ignores output path when filename functions move a chunk #14873

System Info

System:
  OS: macOS 26.5.2
  CPU: (14) arm64 Apple M3 Max
Binaries:
  Node: 24.16.0
  npm: 10.9.8
  pnpm: 11.8.0
npmPackages:
  @rspack/core: 2.1.4

Also reproduced against current main at cfa680e76b623c42d13088a6d46bfcd1f75da2f7.

Details

The incremental JavaScript chunk render cache can reuse source generated for a different output path.

The reproduction uses an output filename function to move an unchanged entry from first.js to deep/nested/first.js. With parser.javascript.url: "new-url-relative", the asset URL in that chunk must change with its depth:

initial: ./58c830cd701afbcb.txt
hot:     ./58c830cd701afbcb.txt
fresh:   ../../58c830cd701afbcb.txt

The hot compilation emits the file at the new path but keeps source rendered for the old path. A fresh compilation emits the correct relative URL.

Invalidation analysis

ChunkRenderCacheArtifact keys the cached source only by chunk content hash. JavaScript rendering resolves the current output_path outside the cache and then passes it into the cached generator (render calls). Thus equal content hashes do not imply equal rendered source.

The resolved output path must participate in the render cache key (or an output-path change must invalidate this cache entry). The module graph, code generation, module/chunk hashes, and chunk membership do not need invalidation: they are unchanged and the filename function already resolves the correct new manifest filename. Only the final render context changed.

Reproduce link

https://github.com/hardfist/rspack-repro-incremental-render-output-path

Reproduce Steps

1. Clone the reproduction repository.
2. Run npm install.
3. Run npm test.
4. Observe that the hot output contains ./<hash>.txt, while the fresh output at the same nested path contains ../../<hash>.txt.