fix(build): make the runtime chunk reproducible across build paths - #46829

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

✨ Files requiring CODEOWNER review ✨

Quality Gate failed

Failed conditions
66.7% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

Full explanation (reference)

The PR description is kept short; this comment preserves the complete plain-language walkthrough of the two root causes, with diagrams, for future readers.

1. The problem in one picture

Mozilla reviewers rebuild MetaMask from our source and compare their result to the .zip we
submitted. Every byte must match.

   We submit                    Reviewer rebuilds
   ─────────                    ─────────────────
   runtime.js      ────vs────   runtime.js      ← ✗ differs ~45% of the time
   background.js   ────vs────   background.js   ← ✓ always matches
   ui.js           ────vs────   ui.js           ← ✓ always matches
   ... 250 more files ...                       ← ✓ always matches

Exactly one file out of ~250 could differ, and only sometimes. That blocked Firefox releases.

2. What the difference actually was

190 bytes out of 790,000. Every single one was the letter c and the letter l trading
places:

  ours:      let c=[];  ...  for(var c=1/0 ... l=!0 ... if(l){
  reviewer:  let l=[];  ...  for(var l=1/0 ... c=!0 ... if(c){
                  ↑                  ↑          ↑        ↑
            same code, same length — just two variable names swapped

That's it. The code is identical in behaviour. But different bytes = different checksum = the
reviewer's automated comparison fails.

3. Why c and l? The letter popularity contest

To make files smaller, our build renames every variable to the shortest possible name (e, t,
a…). This is done by a tool called SWC.

SWC doesn't hand out letters alphabetically. It runs a popularity contest: it counts how
often each letter appears in the file, then gives the most-used variable the most popular letter.
(Reusing popular letters compresses better when the file is gzipped.)

For our runtime.js, the ranking comes out like this:

  rank:    1   2   3   4   5   6   7     8   9     10  11  12
  letter:  e   t   r   a   s   o   n  │  c   l  │  i   m   p
  count: 20013 ... ... ... ... ... 7615│7194 7269│ ...
                                       └────────┘
                                   7194 vs 7269 — essentially TIED

c and l are neck and neck. A difference of one single character anywhere in the file can
flip which one wins — and then every variable that was going to get rank 8 gets l instead of
c, and vice versa. 190 swaps.

Every other file in the build has a comfortable margin between its 8th and 9th letters, which is
why only runtime.js was ever affected.

4. So what changes the letter count? Temporary filenames

runtime.js is the file that knows where all the other files live. It contains a lookup table of
filenames, and those filenames contain content hashes written in hex:

// inside runtime.js — a table of ~160 filenames
{ "46":"e23a6c9490339b890118", "110":"682055cc237ca3ec5279", "133":"bedf0a792fcf955c01a1", ... }
       └─ hex: 0 1 2 3 4 5 6 7 8 9 a b c d e f ─┘
                                    ↑
                          hex contains 'c'  …but never 'l'

That's ~3,200 hex characters, holding roughly 200 cs and zero ls.

So the c-vs-l contest is decided almost entirely by how many cs happen to land in those
random-looking hashes:

  number of 'c' in the table      who wins rank 8      resulting file
  ──────────────────────────      ───────────────      ─────────────────
         ≤ 199                          l              runtime.1fcc8942….js   ✗
         ≥ 200                          c              runtime.b574af00….js   ✓ (what we shipped)

  A random build produces:  201 ± 14  ← the threshold sits right in the middle
                                         → a ~45% / 55% coin flip

This is the "flakiness." It was never random corruption — it was a coin flip with a razor-thin
margin.

5. And why did the hashes change for the reviewer? The folder name

The last piece. Those hashes are computed from each source file's content plus its source-map
metadata — and our build accidentally puts the full absolute path into that metadata.

  We build in:        /home/runner/work/metamask-extension/
  Reviewer builds in: /output/comparison_v13.47.1/metamask-extension-13.47.1/
                      └──────────────── different text ────────────────┘
                                          ↓
                      every file's hash changes → the hex table changes
                                          ↓
                      the 'c' count changes → coin flip → c/l may swap

This is why our earlier experiments behaved so strangely: renaming the build folder changed the
outcome, but it wasn't about the folder being longer — any different folder name reshuffles the
hashes and re-tosses the coin.

Technical detail, for the curious: webpack normally strips absolute paths out of this
metadata, but only when a plugin hands it a structured object. Ours hands it a plain text
string, which webpack passes through untouched. One-line bug, 11,000 affected files.

6. Why it was so hard to find: the evidence erases itself

The hex table is only temporary. After the renaming step, webpack replaces those placeholder
hashes with the real final ones — which are identical for everyone, because every other file
matches.

  Build step                          Is the hex table path-dependent?
  ──────────────────────────────      ────────────────────────────────
  1. compile all files                 —
  2. compute temporary hashes          ← path leaks in here
  3. SWC renames variables             ← decision made here, using the temp hashes  ⚠
  4. replace temp hashes with real     ← evidence wiped clean here
  5. write the .zip                    → table looks identical; only the
                                         variable names still differ

So if you looked at the two final files, you'd see only c↔l swaps and no reason for them.
The cause had already been overwritten. That's the whole mystery.

7. The full chain, end to end

  ┌─────────────────────────────────────────────────────────────────────┐
  │  Different build folder                                            │
  │  (or just a different build, see note below)                        │
  └────────────────────────────┬────────────────────────────────────────┘
                               ▼
  ┌─────────────────────────────────────────────────────────────────────┐
  │  Absolute path gets baked into every file's hash                    │
  └────────────────────────────┬────────────────────────────────────────┘
                               ▼
  ┌─────────────────────────────────────────────────────────────────────┐
  │  runtime.js's table of hex filenames changes                        │
  │  → the number of letter 'c' moves by a few                          │
  └────────────────────────────┬────────────────────────────────────────┘
                               ▼
  ┌─────────────────────────────────────────────────────────────────────┐
  │  SWC's letter popularity contest flips:  c ⇄ l                      │
  │  → 190 variable names swap                                          │
  └────────────────────────────┬────────────────────────────────────────┘
                               ▼
  ┌─────────────────────────────────────────────────────────────────────┐
  │  Temp hashes replaced by real ones — cause erased, swap remains      │
  └────────────────────────────┬────────────────────────────────────────┘
                               ▼
  ┌─────────────────────────────────────────────────────────────────────┐
  │  runtime.js has a different checksum → Mozilla's comparison fails   │
  └─────────────────────────────────────────────────────────────────────┘

Note — the second, smaller cause. Even in the same folder, roughly 1–2% of files get
slightly different metadata on each build. SWC keeps a reusable cache of our process.env
values, and entries in that cache carry stale position markers from whichever file happened to
be compiled first — which depends on thread timing. Harmless in itself, but it nudges the c
count by a unit or two, which is enough to flip the coin when it's already balanced on edge.
This is why the reviewer script failed ~2 times in 10 even at a fixed path.

8. The fix

Two independent things, ranked:

① Stop the contest (recommended, one line). Tell SWC to hand out letters in fixed alphabetical
order instead of by popularity — mangle: { disableCharFreq: true } on runtime.js. Then nothing
in the file's content can influence variable names, so neither cause above can reach us.

  Verified: 0 name swaps across the entire range of 'c' counts; identical file size.

This replaces the current workaround (PR #46236, which turned renaming off entirely for that one
file and cost ~12–16 KB).

② Stop the path leak (good hygiene, one line). Hand webpack a structured object instead of a
string, so it strips the absolute path as intended.

  Verified: path-dependent files drop from 11,331 → 203.
  Not sufficient on its own — the 203 are the cache-timing cause from the note above.

Plus two upstream reports worth filing: SWC's stale cache positions, and webpack's
string-vs-object inconsistency.

Recap in three sentences

Our runtime.js contains a list of temporary filenames written in hex. The minifier picks short
variable names by counting letters in the file, and hex digits tip a dead-even tie between c and
l — so anything that changes those temporary filenames (notably the build folder's name) swaps
190 variable names. A later build step rewrites the temporary filenames with identical final ones,
which is why the two files looked inexplicably different with no visible cause.

Superseded by #46845, which goes straight to the end state: it fixes the root causes (swc loader source map, @swc/core 1.16.2, html-bundler absolute requests, React Compiler stats in the hashed buildMeta) and reverts the #46236 workaround instead of adding disableCharFreq. The explanation comment above stays as the reference for causes 1–2; causes 3–4 are described in #46845.