Vite 8.3.6 fixes hash drift: chunk import map signatures now use stable module ids
Import map hashes now use stable module ids so builds are reproducible, dynamic imports with queries collect CSS dependencies correctly, and overlapping close calls wait.
Vite shipped 8.3.6 on November 5. Four bug fixes, and one of them held my attention: chunk import map hash signatures now use stable module ids.
Why hash drift hurts
Anyone who has deployed a frontend knows the pattern: no code changed, you rebuild, and every artefact filename is different. CDN caches invalidate, users re-download everything, and the build cache you carefully warmed is worthless.
The cause is usually not “the content changed” but something feeding the hash is unstable: absolute paths, iteration order, or how module ids are generated. Any one of them jitters, and the hash jitters with it.
This release fixes the last one. Import map hash signatures used a less stable form of module id; now they use stable ones. The practical effect for CI: build the same source twice and the output should be byte-identical.
Dynamic imports with queries missed CSS dependencies
Second: dynamic imports carrying a query, such as import('./foo.css?inline'), were resolved incorrectly when collecting CSS dependencies. The symptoms range from wrong CSS order to styles never being collected at all. This kind of bug looks fine in development and breaks after build, which makes it the worst kind to debug.
Third is internal but real: overlapping plugin container close() calls now await each other. Without that, cleanup could race, showing up as intermittent file locks and temporary directories that will not delete.
One more for bundled dev
Fourth: bundled-dev now allows named imports from Node built-in modules (import { readFile } from 'node:fs/promises'). That form used to error in the bundled development mode, while default imports worked.
This connects to Vite 8’s bundled dev direction, which runs the dev server through a bundler. It buys cold start and HMR speed at the cost of edge cases like this one.
What I do
My current policy for frontend build tool patches is “follow, but do not bundle into a release”: upgrade in my own CI first and check two things.
- Are two consecutive builds byte-identical? That is exactly what this release fixes
- Did CSS order change? Fixes two and three live in that neighbourhood
If both pass, take it. The routine costs ten minutes and has saved me at least three investigations into “some styles changed quietly after deploy”.
One aside: the biggest payoff of the 8.x line is bundled dev, and so is its biggest risk. Patch releases exist to sand down those edges. Should you upgrade now? If 8.3.x already runs well in your project, there is no reason to stay on 8.3.5.
Comments
…