Half of Vite 8.3.5's fixes live in bundled-dev: bundling during dev is still catching up

Vite 8.3.5 shipped on October 21 with 21 fixes. The first thing you notice is the distribution: eight carry the bundled-dev prefix, two are build fixes about chunk import maps, and the rest scatter across CSS, dependency bumps and platform details. The 6.x line got 6.4.5 the same day.

What bundled-dev is, and why it eats half the list

bundled-dev is the dev mode Vite 8 introduced: dev goes through the bundler, instead of the classic dev server’s per-request module transform. The motivation is straightforward — on a project with thousands of modules the browser fires thousands of requests and cold start is painful; bundle first and the request count drops to single digits.

The cost: once dev and build share one bundling pipeline, every “dev-only” semantic has to be reimplemented. The eight fixes in 8.3.5 are exactly that:

Fix	What it means
Stop HMR propagation at modules no longer imported	after removing an import, edits still triggered updates and the page flickered
Map forwarded error stacks through the bundle source maps	otherwise line numbers in dev point at the bundle
Apply server.origin to asset URLs	assets 404 behind a proxy or custom origin
Declare utf-8 charset in the fallback page	mojibake on the not-found page
Ignore build.chunkImportMap in dev	build-only config leaked into dev
Include user import.meta.env.* defines in the env object	custom variables unreadable in dev
Normalize served output files	path normalization
Remaining details	—

Read as a whole, the table describes a scheme that runs dev as a build and is still restoring the experience dev is supposed to have: HMR boundaries, readable stacks, visible env vars. All of these came for free in a classic dev server because each had its own implementation path; merge the paths and you rebuild them one by one.

My read: the direction is right (cold start and request count are real pain), but it turns a stable developer experience back into something that needs constant repair. Projects on 8.x should expect a few bundled-dev entries in every patch release.

Chunk import maps: correctness, not comfort

Two build fixes deserve their own section:

• Handle missing chunk import maps (#23777): some chunks referenced import map entries that did not exist.
• Include preload dependencies in chunk import map hashing (#23793): the hash covered the chunk but not the dependencies it preloads — so a dependency change produced the same filename, and browsers served stale code from cache.

The second is a textbook cache-key design bug: the hash function’s input was missing a term. It looks fine, and it only misbehaves in the “dependency changed, chunk did not” combination — a change ordering that is almost impossible to cover in tests.

A percent sign in CSS

One fix looks trivial: a literal % inside url() no longer fails the build.

/* this used to fail the build */
.hero {
  background-image: url('/img/100%25-banner.png');
}

In a URL, % introduces percent-encoding and must be written %25; if the parser decodes before validating, %25 becomes % and then fails validation. That is an ordering problem between decoding and checking — the same class of mistake as Node’s tls and dns fixes last week, except there it was a security issue and here it is a failed build.

Upgrade or not

Upgrade. It is a patch release, none of the 21 items change the API, and the two chunk import map fixes are about output correctness — a wrong hash means users can receive mismatched code, which shows up as “one user’s blank page, fixed by a refresh” and is nearly impossible to diagnose from reports.

One caution: if you run bundled-dev, clear node_modules/.vite after upgrading. Those caches encode assumptions about the bundling pipeline and surviving a version change produces the classic “I edited code and nothing happened”.

A note on 6.x: 6.4.5 shipping the same day means the 6 line is still maintained. If you are on 6, do not rush a major upgrade — the gains in 8 are mostly bundled-dev and the rolldown pipeline, and if build time is not your pain point there is no migration cost worth paying.