One dot, one dash, and 131 kB shipped twice

Yash Bavadiya — Tue, 28 Jul 2026 11:39:24 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

Nuxt is the Vue meta-framework. It sits on top of Vite, and a lot of what it does at build time is configure Vite carefully enough that you never have to think about it.

Issue #22966 was filed in August 2023. Importing the same WebAssembly binary from app code and from a web worker made the build emit two copies of it, identical bytes under two filenames, both shipped to the browser. It stayed open for three years.

It is fixed now. PR #35866 was merged into nuxt/nuxt as df18c4a, and #22966 closed with it.

Bug Fix or Performance Improvement

Nuxt overrides Vite's asset naming for the client build, so assets come out as _nuxt/[name].[hash].[ext] rather than Vite's default [name]-[hash][extname].

Vite builds workers in a separate sub-build with its own output configuration. Nuxt set the naming pattern on the client build and never passed it down to that sub-build, so the worker build kept Vite's default.

That only matters when one asset is reachable from both graphs. In my repro the client build emitted shared.Day3YyQn.wasm and the worker build emitted shared-Day3YyQn.wasm. Same content hash, same 131,089 bytes, same sha256 (313d428c...), one dot and one hyphen apart. Rollup deduplicates within a build rather than across two of them, so nothing catches it and the dist ships both.

The runtime cost is worse than the disk cost. Two distinct URLs means the browser cannot reuse the first download for the second request, so a cold load transfers the binary twice even though _nuxt assets are served immutable. The app fetches one copy, the worker fetches the other, and the cache never gets a chance to help.

Nothing errors and nothing warns. The build is green, the app works, and the only symptom is one extra file in a directory listing you have no particular reason to read. That is most of why it lasted three years.

Code

Merged PR: https://github.com/nuxt/nuxt/pull/35866
Merge commit: df18c4a8f1fa9b8577d3cc29a8965f6449adf698
Closes: https://github.com/nuxt/nuxt/issues/22966

The whole fix is in packages/vite/src/vite.ts. The naming function was inline in the client build's output options, so the first move was to lift it out:

+import type { PreRenderedAsset } from 'rolldown'

+  // https://github.com/vitejs/vite/blob/main/packages/vite/src/node/build.ts#L464-L478
+  const assetFileNames = nuxt.options.dev
+    ? undefined
+    : (chunk: PreRenderedAsset) => withoutLeadingSlash(join(nuxt.options.app.buildAssetsDir, `${sanitizeFilePath(filename(chunk.names[0]!))}.[hash].[ext]`))

Then point both builds at the same value:

       build: {
         rolldownOptions: {
           output: {
             sanitizeFileName: sanitizeFilePath,
-            // https://github.com/vitejs/vite/blob/main/packages/vite/src/node/build.ts#L464-L478
-            assetFileNames: nuxt.options.dev
-              ? undefined
-              : chunk => withoutLeadingSlash(join(nuxt.options.app.buildAssetsDir, `${sanitizeFilePath(filename(chunk.names[0]!))}.[hash].[ext]`)),
+            assetFileNames,
           },
         },
       },
+      worker: {
+        rolldownOptions: {
+          output: {
+            // matching the main build ensures assets shared with workers are emitted only once
+            assetFileNames,
+            sanitizeFileName: sanitizeFilePath,
+          },
+        },
+      },

Both builds now resolve the shared asset to the same name, so it is emitted once. User-supplied vite.worker options still take precedence through the mergeConfig that was already there, so this sets a default rather than taking the option away from anyone.

My Improvements

Finding it

I did not trip over this in a project. I went looking for it.

The contest wanted a fix with a defensible before/after number, so I started at Nuxt's issue tracker rather than at code, filtering for open, unassigned, triaged by a maintainer, and measurable in something honest like bytes. The first thing that filter told me was that nuxt/nuxt has no open unassigned issues labelled bug at all. The team clears confirmed bugs fast. What is left is the long tail of p3-minor things nobody has gotten around to, which is exactly where you should be shopping.

#22966 had been open since August 2023. Import the same WebAssembly file from your app and from a web worker, and the production build ships two full copies of it. Someone had confirmed it still reproduced eleven days before I found it. There was a competing PR too, closed by its author four days earlier, which I read anyway, because a closed PR is a free map of the terrain.

My first repro did not reproduce anything. A minimal valid wasm file is eight bytes, eight bytes is well under Vite's 4 kB inline limit, and my duplicated asset quietly became a base64 string inside a JS chunk. Take two used a 131 kB binary padded with garbage. Then the worker build failed outright, because I had written top-level await and Vite bundles workers as IIFE by default, where that is not legal.

Both wrong turns were the same lesson in different clothes. The worker build and the app build are separate pipelines with separate defaults. I did not know yet that this was the answer, but I had now been told twice.

Then a build finished and the answer was sitting in the directory listing.

shared.Day3YyQn.wasm    131 kB
shared-Day3YyQn.wasm    131 kB

Same name, same size, same content hash Day3YyQn in both filenames, identical sha256. One character of difference, a dot against a dash. That killed my first theory on the spot: if the hashes matched, this was not two assets and not a content-tracking bug. Both builds agreed exactly on what the file was. They disagreed on what to call it.

So I grepped the builder for where names come from. assetFileNames appears once in the entire package, in packages/vite/src/vite.ts, setting Nuxt's pattern for the client build. worker appears zero times. The absence was the bug. Nuxt renames assets for the main build, nothing tells the worker sub-build, it falls back to Vite's default, and the bundler cannot collapse two files whose names do not match.

The fix was almost anticlimactic after that. Hand the worker build the same naming function the app build already uses. Three years open, one character of symptom, one config block.

One value, not two copies

The obvious fix is to paste the naming function into the worker config as well. That works and I did not do it, because two copies of a naming rule is exactly how the two builds drift apart again. Someone tweaks the client pattern in a year, does not know a worker copy exists, and the bug comes back wearing different clothes. Hoisting it to a single const and referencing it from both places means there is one rule and nowhere for a second one to hide.

Lifting it out had one consequence worth mentioning. Inline, the chunk parameter was contextually typed by the option it was being assigned to. Hoisted, that context is gone and TypeScript has nothing to infer from, so the annotation has to be explicit and PreRenderedAsset gets imported from rolldown (Nuxt's Vite runs on rolldown, hence rolldownOptions rather than rollupOptions).

The dev guard comes along for free. assetFileNames is undefined in dev, and since the worker build now reads the same value, dev behaviour is unchanged for both builds rather than needing its own branch.

The test is the real deliverable

The change is small enough to be unconvincing on its own. Looking at a few lines of Vite options, a reviewer has no way to tell whether it fixes the reported problem or just shuffles names around.

So the PR ships a fixture at test/fixtures/worker-assets. An app component imports the asset directly, a module worker imports the same file and posts its URL back:

<script setup lang="ts">
import wasmUrl from './shared.wasm?url'

const workerUrl = ref('')
onMounted(() => {
  const worker = new Worker(new URL('./worker.ts', import.meta.url), { type: 'module' })
  worker.onmessage = (e) => { workerUrl.value = e.data }
})
</script>

The fixture config sets assetsInlineLimit: 0. Without it the test asset is small enough that Vite inlines it as a data URI, no file is emitted at all, and the assertion passes for a reason that has nothing to do with the fix. A test that is green on main for the wrong reason is worse than no test.

The test itself:

it('emits a single copy of an asset imported from both app and worker', async () => {
  const assetsDir = join(outputDir, 'public', '_nuxt')
  const files = await readdir(assetsDir)
  const wasmFiles = files.filter(file => file.endsWith('.wasm'))
  expect(wasmFiles).toHaveLength(1)

  const chunks = await Promise.all(files.filter(file => file.endsWith('.js')).map(async file => [file, await readFile(join(assetsDir, file), 'utf-8')] as const))
  const referencedAssets = new Set(chunks.flatMap(([, code]) => code.match(/[\w.-]+\.wasm/g) ?? []))
  expect([...referencedAssets]).toEqual(wasmFiles)

  // the worker chunk and an app chunk must each point at the single emitted copy
  const referencingChunks = chunks.filter(([, code]) => code.includes(wasmFiles[0]!))
  expect(referencingChunks.some(([file]) => file.startsWith('worker-'))).toBe(true)
  expect(referencingChunks.some(([file]) => !file.startsWith('worker-'))).toBe(true)
})

Counting files alone would pass if the fix emitted one copy and left the worker pointing at a name that no longer exists, which is a worse bug than the one being fixed. The reference assertions exist to catch that.

It fails on main and passes with the change. That is what makes the diff trustworthy, and it is what stops this coming back the next time someone touches worker config.

A prior attempt

PR #35828 went after the same bug earlier and was closed by its author. I found it while triaging, read the diff, and implemented independently. The difference in mine is the regression test.

Responding to review

CodeRabbit reviewed the PR and flagged a gap in the test's coverage. I checked the finding against the code instead of applying the suggested patch, because automated reviewers produce real bugs and confident nonsense in about equal measure and reading the lines yourself is the only way to tell which one you got. This one was right, so I pushed a follow-up commit (test: check app and worker chunks reference the shared asset) tightening the assertion. Follow-up rather than a force-push, so the reviewer could see what had changed since they looked.

Numbers

Measured on a separate benchmark playground on my contest/dedupe-worker-assets branch, not the test fixture. The app and a module web worker both import a 131,089 byte shared.wasm via ?url and instantiate it with WebAssembly.instantiateStreaming. Three builds per side, rebuilding @nuxt/vite-builder for each side. Output was byte-identical across all runs, so the median is every run.

	before	after	delta
`.wasm` files in `.output/public/_nuxt`	2	1	-1 file
bytes of those files	262,178	131,089	-131,089 (-50%)
total `.output/public` bytes	398,045	266,956	-131,089 (-32.9% of this fixture's client dist)
cold-load wasm bytes transferred	262,178	131,089	-131,089

Both copies in the before state carried the same sha256, 313d428c....

I also checked it end to end rather than trusting the file listing. Before the fix, the app instantiates /_nuxt/shared.Day3YyQn.wasm while the worker instantiates /_nuxt/shared-Day3YyQn.wasm, and both URLs return 200 with content-length 131089. After, both instantiate the same URL successfully and the old duplicate name returns 404.

What these numbers do not cover:

Savings apply only to apps that import the same asset from both the app and a web worker (any asset type, not just wasm). Apps without shared worker assets see zero change.
The absolute byte number scales with the size of the shared asset. 131 KB is the synthetic fixture's asset, not a universal figure. Real-world wasm modules are commonly larger.
No build-time or runtime CPU claims are made. The fix changes file naming only.
Measured with the Vite (rolldown) builder only. The webpack and rspack builders are untouched by the fix.

All of it regenerates from bench/run.sh, including raw logs, per-run sha256 lists, and HTTP transcripts, so any number above can be checked rather than taken on trust.

CI's own benchmark suite (CodSpeed) reported no performance change. Its footnotes are worth reading though: no successful run existed on the true base commit, so it compared against a nearby one, and three skipped benchmarks used substituted baselines. I would call that corroboration that nothing regressed rather than proof.

Scope

One value hoisted, one config block added, one fixture, one test. No refactoring of the code around it, no unrelated cleanups, nothing bundled in that a reviewer had not asked for. A three-year-old bug is tempting to treat as license for a bigger change, and I think the reason this merged in hours rather than sitting in a queue is that there was almost nothing in the diff to argue about.

DEV Community: Yash Bavadiya