feat(bundled-dev): support hotUpdate and handleHotUpdate hook

[h-a-n-a]

Makes Vite's hotUpdate and handleHotUpdate plugin hooks work in bundled dev. Built on top of rolldown's new dev-only hotUpdate hook (rolldown/rolldown#10305).

Problem

In bundled dev, the rolldown engine owns the module graph and the update flow. When a file changes, hooks run inside the engine, and the engine passes plain module ids. Vite plugins expect Vite's own types: EnvironmentModuleNode objects, a moduleGraph, and one shared context per change event. With no translation between the two sides, every plugin that uses these hooks does nothing in bundled dev.

Even a plugin as small as this had no effect before this PR:

{
  name: 'my-plugin',
  hotUpdate({ file, modules }) {
    if (!file.endsWith('.css')) return
    return modules.filter((m) => m.id !== skippedId) // never ran in bundled dev
  },
}

Design

flowchart TB
  A[Vite plugin<br/>hotUpdate with module nodes] --> B[adapter in bundledDevHmr.ts<br/>one wrapper per plugin]
  B --> C[rolldown hotUpdate hook<br/>plain module ids]
  C --> D[rolldown dev engine<br/>owns graph and update flow]

Loading

Two new pieces, both in bundledDevHmr.ts:

• A module graph view (BundledModuleGraph) — an object that looks like Vite's module graph but stores no graph data of its own. It creates a Vite module node for an id the first time that id is asked for, then reuses the same node. Identity matters here: plugins compare nodes by reference and store their own state on them. A node's info, importers, and importedModules are read live from the engine, so they stay correct after every rebuild. Nothing has to be kept in sync by hand. Writing to a node does nothing, because the engine owns the real graph.
• A hook adapter (BundledDevHotUpdateAdapter) — every Vite plugin that has one of the two hooks gets its own wrapper, registered as that plugin's rolldown hotUpdate hook. Plugin order, and the rule that a returned module set replaces the previous one, then come from rolldown's own driver. The adapter does not re-implement them. The wrapper turns ids into nodes before it calls the Vite hook, and turns nodes back into ids after the hook returns.

The main design rules:

• Each layer keeps its own types. The engine uses ids. Vite plugins use nodes. Translation happens only at the boundary, inside the adapter.
• Only top-level Vite plugins are wrapped. A plugin swapped in for one environment with applyToEnvironment is a rolldown plugin. Its hotUpdate already expects ids, so it stays unwrapped.
• One shared state per changed file, as in Vite. A pre-ordered hook opens the state for the event and expands the module set to every module of that file, so query variants such as file.vue?type=style are included. All wrappers for that file share one options object. A change made by one plugin, for example a new read function, is therefore visible to the next plugin. A post-ordered hook merges the modules buffered through moduleGraph.invalidateModule and closes the state.
• invalidateAll rebuilds everything and reloads the page. Bundled dev has no partial invalidation to fall back on, so this is what the flag can mean here.
• The legacy hook keeps its Vite behavior. handleHotUpdate receives the shared HmrContext with mixed module nodes, runs only for updates, and warns that it is deprecated.

Tests

End-to-end coverage lives in the rolldown repo's dev-server test suite (hmr-hot-update-hook-vite, 8 browser specs). It covers the common plugin patterns:

• replacing the module set
• buffering invalidateModule calls, the way the Tailwind plugin does it
• sending a custom message with read() and hot.send, the way markdown page plugins do it
• the legacy shared-context read chain (unocss together with plugin-vue)
• expanding one file into its sub-modules (Vue SFC)
• suppressing an update
• invalidateAll

Unit tests in this repo will follow in a later PR.

[h-a-n-a]

Hold this. We might need to move getModulesByFile to the Rolldown side.