bundledDev: memoryFiles keeps every rebuild's hashed chunks and every HMR patch, so dev server memory grows with each edit #23781

Describe the bug

With experimental.bundledDev, nothing is ever removed from BundledDev.memoryFiles until the server closes.

• storeOutputFiles only calls memoryFiles.set.
• getRolldownOptions forces chunkFileNames: 'assets/[name]-[hash].js' and assetFileNames: 'assets/[name]-[hash][extname]'.

So every rebuild that changes a chunk stores it, and its source map, under a new name, next to all the previous copies. HMR patches (hmr_patch_N.js + .map) are never removed either. Every old file stays served.

There are two ways to hit it.

1. A chunk shared between entries (multiple rolldownOptions.input entries, or devMode: { lazy: false } with dynamic imports). Each edit to a module in a shared chunk adds that chunk and its map again, plus every hashed chunk that imports it, because the hash change cascades. In our app, with ~230 entries, 20 edits to a module most entries import took memoryFiles from 1,919 to 28,479 files, and the process RSS from 3.9 GB to 12.1 GB.
2. The default config with a page open. Each edit adds hmr_patch_N.js and hmr_patch_N.js.map. That's slower growth, but it's unbounded for a long-running session.

Expected: memoryFiles holds the latest build output, plus the patches that are still pending.

Actual: it holds every file ever emitted.

storeOutputFiles has // NOTE: don't clear memoryFiles here as incremental build reuses the files. In the reproduction, though, each rebuild hands storeOutputFiles the complete output, unchanged entries included. A possible fix:

• Remember the previous output's file names, and delete the ones the new output does not contain.
• Delete an HMR patch or lazy payload once the client reports it delivered (vite:bundled-dev:payload-delivered), or keep only the last few.

A workaround for build output, not for HMR patches: a plugin that removes the hash, so each rebuild overwrites the same keys:

{
  name: 'unhashed-dev-chunks',
  outputOptions: options => ({ ...options, chunkFileNames: 'assets/[name].js', assetFileNames: 'assets/[name][extname]' }),
}

Reproduction

https://github.com/asapach/vite-issue-memoryfiles

Steps to reproduce

Case 1, a chunk shared between two entries (scripted):

1. npm install
2. npm run repro

The script uses bundledDev.memoryFiles and devEngine internals only to count the files and to wait for each rebuild deterministically. It makes five code edits to src/shared.js, then restores it.

Case 2, the default config:

1. npm run dev
2. Open http://localhost:5173/
3. Edit src/shared.js and save, three times, with different code each time.
4. curl -i http://localhost:5173/hmr_patch_0.js returns 200, as do hmr_patch_1.js and hmr_patch_2.js. All of them stay in memoryFiles until the server closes.

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (18) x64 Intel(R) Core(TM) Ultra 5 135H
    Memory: 9.03 GB / 31.46 GB
  Binaries:
    Node: 24.16.0
    npm: 11.13.0
    pnpm: 11.11.0
  Browsers:
    Chrome: 155.0.8059.40
    Edge: Chromium (152.0.4191.53)
  npmPackages:
    vite: 8.3.4 => 8.3.4
    rolldown: 1.2.14 (dependency of vite)

Used Package Manager

npm

Logs

initial build: 6 files
after edit 1: 8 files
after edit 2: 10 files
after edit 3: 12 files
after edit 4: 14 files
after edit 5: 16 files
assets/main.js
assets/other.js
assets/shared-1euN4Vmf.js
assets/main.js.map
assets/other.js.map
assets/shared-1euN4Vmf.js.map
assets/shared-Dt-zbz8f.js
assets/shared-Dt-zbz8f.js.map
assets/shared-BkId7QYW.js
assets/shared-BkId7QYW.js.map
assets/shared-DB4C89Nn.js
assets/shared-DB4C89Nn.js.map
assets/shared-BcUH7Yx-.js
assets/shared-BcUH7Yx-.js.map
assets/shared-CGgg6g2c.js
assets/shared-CGgg6g2c.js.map

GET /assets/shared-1euN4Vmf.js (initial build) -> 200, still the original code

bundledDevClient.mjs, @rolldown/experimental-runtime.mjs, @vite/client, @vite/env, assets/index.js, assets/index.js.map,
index.html, hmr_patch_0.js, hmr_patch_0.js.map, hmr_patch_1.js, hmr_patch_1.js.map, hmr_patch_2.js, hmr_patch_2.js.map
GET /hmr_patch_1.js -> 200

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.