fix(build): make Firefox builds reproducible across paths and remove the runtime-chunk mangling workaround - #46845

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.

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​swc/​core@​1.16.1 ⏵ 1.16.2				-1

View full report

Priority	Alert  (click "▶" to expand/collapse)	Action
	Potential code anomaly (AI signal): npm @swc/core is 66.0% likely to have a medium risk anomaly Notes: This module is a configuration loader/merger, but it performs dynamic module loading via require() using a runtime-derived specifier/path from compileBundleOptions(config). The default behavior (config undefined -> require(".")) can cause loading of whatever Node resolves from the current working directory, which is risky if the caller’s config input or the process working directory can be influenced. Aside from require()-driven execution and error-message information disclosure, the snippet shows no overt malicious payload behavior. Confidence: 0.66 Severity: 0.60 From: package.json → npm/@swc/core@1.16.2 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@swc/core@1.16.2. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.	Warn

View full report

Background: why four unrelated bugs all showed up as the same c/l swap

Read this once. The four fix comments below each refer back to it.

The symptom

Mozilla reviewers rebuild MetaMask from source and compare their result to our .zip, byte for byte. One file out of about 250, runtime.js, sometimes differed. It differed by exactly 190 bytes, every one of them the letter c and the letter l trading places in variable names:

  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, same behaviour. Different checksum, failed review.

Step 1: short variable names are assigned by a popularity contest

To shrink files, our build (via a tool called SWC) renames every variable to one letter. It does not go alphabetically. It counts how often each letter already appears in the file and gives the most-used variable the most popular letter, because that compresses better with gzip.

For runtime.js the ranking came out as:

  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:  …   …   …   …   …   …   …  │7194 7269│  …   …   …
                                       └────────┘
                                   essentially TIED

So one extra c anywhere in the file flips which letter wins rank 8, and every variable that would have been c becomes l and vice versa. That is the 190 swaps.

Step 2: runtime.js contains about 3,200 hex characters that are temporary

runtime.js is the file that knows where all the other files live, so it holds a table of their names, which contain hashes written in hex:

{ "46":"e23a6c9490339b890118", "110":"682055cc237ca3ec5279", ... }   // ~160 entries
          hex alphabet: 0 1 2 3 4 5 6 7 8 9 a b c d e f
                                            ↑
                                   has 'c', never 'l'

Two things about these hashes matter:

1. They are provisional. webpack computes them early, SWC renames variables while they are still in the file, and only afterwards webpack replaces them with the final hashes. So they influence the popularity contest and then disappear. That is why the two differing files showed no visible cause.
2. Each one is a fingerprint of a chunk of our code, computed from everything webpack knows about the modules inside: their code, their source maps, and some metadata.

Step 3: anything that leaks into a module fingerprint leaks into the alphabet

  something build-specific gets into a module's fingerprint
        ↓
  that chunk's provisional hash changes (20 new hex chars)
        ↓
  the number of 'c' in runtime.js's table shifts by a few
        ↓
  'c' vs 'l' popularity flips  →  190 variable names swap
        ↓
  webpack overwrites the provisional hashes → evidence gone, swap remains

The four fixes in this PR each close one way that something build-specific (the absolute path of the build directory, or which thread happened to compile a file) was getting into those fingerprints. None of them touches SWC. SWC was doing exactly what it is designed to do.

With all four closed, the fingerprints depend only on the source code, so the contest has the same outcome on every machine and in every directory, and the special case from #46236 (not renaming variables in runtime.js at all) can be removed.

Fix 1 of 4: the build folder's name was baked into every module's fingerprint

File: development/webpack/utils/loaders/swcLoader.ts (3 lines changed)
Affected: 11,331 of 11,435 modules, essentially everything.

What was happening

When our swc loader compiles a file, it hands webpack two things: the compiled code and a source map (the debugging metadata that says "this output line came from that input line"). The source map names the original file it describes, and SWC writes that as the full absolute path:

{ "sources": ["/Users/alice/Repositories/metamask-extension/app/scripts/background.ts"], ... }

webpack knows this is a problem and normally scrubs it: it rewrites the path relative to the project (webpack://./scripts/background.ts) before using the map in the module's fingerprint. But it only does that when the loader gives it the map as a parsed object. Our loader gave it the map as a JSON string, and webpack's scrubbing code starts with:

if (typeof sourceMap === "string" || !Array.isArray(sourceMap.sources)) {
  return sourceMap;        // ← hands the string back untouched
}

So the raw string, absolute path included, went straight into the fingerprint of every module we compile:

  /home/runner/work/metamask-extension/…      (our CI)
  /output/comparison_v13.47.1/metamask-…      (the reviewer's script)
            different text → every fingerprint differs → see background

This is why the reviewers' rebuild, which runs in a different directory than our release build, kept failing while our own CI builds never did.

The fix

Give webpack the parsed object instead of the string, so its own scrubbing runs:

-transform(src, options).then(({ code, map }) => cb(null, code, map), cb);
+transform(src, options).then(
+  ({ code, map }) => cb(null, code, map === undefined ? map : JSON.parse(map)),
+  cb,
+);

The existing unit test asserted the string form. It now asserts the object form and explains why.

How we know it works

Per-module fingerprint dumps of the same tree built in a 43-character and a 115-character path: before the fix, 11,331 modules had different fingerprints. After it, only the modules affected by fixes 2 to 4 still did.

Fix 2 of 4: @swc/core remembered where the first file's values came from

Change: @swc/core 1.13.3 → 1.16.2, plus three adjustments that version needs (listed below).
Affected: every module that mentions process.env.SOMETHING, a few hundred, varying from build to build.

What was happening

Our build replaces process.env.NODE_ENV, process.env.IN_TEST, etc. with their literal values while compiling, so that if (process.env.IN_TEST) can be optimised away. SWC does this substitution for us.

To avoid re-parsing the same handful of values thousands of times, SWC parsed them once per process and cached the result. The problem: a parsed value carries a position ("I came from byte N of the file being compiled"), and the cached copy kept the position from whichever file happened to be compiled first.

  worker starts   →  compiles   a.tsx  (12 KB)   → parses 'production' @ byte 12,340, caches it
                  →  compiles   b.tsx  (3 KB)    → reuses cache: 'production' "@ byte 12,340"
                                                    …but b.tsx only has 3,000 bytes
                                                    → one source-map entry points at garbage

That one garbage entry changes b.tsx's source map, which changes its fingerprint. And which file is compiled first depends on thread scheduling, so the set of affected modules differed from one build to the next, even in the same directory. This is the part of the problem that fix 1 alone cannot explain: builds in the same folder still disagreed with each other occasionally.

The fix

Already fixed upstream. swc-project/swc#12129 drops the stale positions from cached values, and #12166 keys the cache correctly (it was keyed on the wrong option, so even packages we had configured with no substitutions were silently getting ours). Both shipped in 1.16.2. This PR bumps to it and brings the three adjustments that version needs:

• .ts and .tsx files get separate loaders (1.16 parses TypeScript generics as JSX when tsx: true).
• IN_TEST is now substituted explicitly for node_modules code. Previously it leaked in by accident through the mis-keyed cache, and @metamask/network-controller relied on it.
• LavaMoat policies regenerated. They gain "process.env.NODE_ENV": true for about 35 third-party packages for the same reason: those packages no longer inherit our substitution, so the policy generator now sees the reference. At runtime webpack still substitutes it, so the bundle behaves exactly as before. The only process.env.NODE_ENV left in the output is inside the policy text itself.

How we know it works

Same tree built twice at the same path: before, 15 to 230 modules had different fingerprints (always only the source-map mappings field). After the bump, 0 of 14,431.

Fix 3 of 4: the HTML pages were compiled with absolute paths inside them

File: our existing yarn patch for html-bundler-webpack-plugin (.yarn/patches/html-bundler-webpack-plugin-npm-4.23.2-*.patch)
Affected: 7 modules, the HTML entry pages (home.html, popup.html, background.html, notification.html, …).

What was happening

Our HTML pages are webpack entry points. html-bundler-webpack-plugin turns each one into a small JavaScript module so webpack can track the scripts and images it references. For <script src="../../scripts/load/bootstrap.ts"> it generated:

module.exports = '…<script src="' + require('/Users/alice/Repositories/metamask-extension/app/scripts/load/bootstrap.ts') + '" defer>…'
                                              ↑ absolute path, written into the module's code

webpack resolves that require() to a module id, so the final HTML is path-independent. But the module's code, with the absolute path, is what goes into its fingerprint. Seven HTML modules give seven provisional hashes, about 140 hex characters in runtime.js's table that changed with the build directory.

Only 7 modules out of 11,435, but the margin between c and l was one character, so this alone was enough to flip it.

The fix

Make the generated code say require('../../scripts/load/bootstrap.ts'), relative to the HTML file. webpack resolves that to exactly the same module, because a module's requests are always resolved relative to its own directory.

The plugin, however, also executes that generated module itself later, with its own mini require(), to splice in the final output filenames. That mini require() looks scripts up by their absolute path. So the patch has two halves, and a scope rule:

  compile time (loader)                        render time (plugin)
  ───────────────────────                      ──────────────────────────────────
  emit  require('../../scripts/x.ts')   ───▶   turn it back into /abs/…/scripts/x.ts
  only for requests made by an HTML            before looking the script up
  entry page itself

The scope rule matters: a stylesheet's url(../webfonts/font.woff2) is compiled in one file (a Sass partial) but executed under another (the root stylesheet), so a relative path would resolve against the wrong directory. Those stay absolute. They are not webpack modules whose fingerprint matters, so nothing is lost.

How we know it works

With this fix, the two-path fingerprint comparison shows 0 differing modules. All 663 output files, including the HTML pages, are byte-identical across paths, and the pages' <script src> attributes resolve to real output files.

Fix 4 of 4: React Compiler statistics were being hashed along with the code

Files: development/webpack/utils/loaders/reactCompilerLoaderWrapper.ts, …/plugins/ReactCompilerPlugin/index.ts (plus comments in …/loaders/reactCompilerLoader.ts)
Affected: about 1,800 modules, every file under ui/ that goes through the React Compiler.

What was happening

Our React Compiler wrapper collects statistics for the --reactCompilerVerbose report. For each function it compiles, it records an event (compiled, skipped or error, the line and column, and the file's absolute path) and stores the list on the module as buildMeta.__reactCompilerStatus__.

buildMeta is the wrong drawer. webpack treats it as "facts about what this module is" and includes JSON.stringify(buildMeta) in the module's fingerprint. So:

"__reactCompilerStatus__": { "events": [
  { "filename": "/home/runner/work/metamask-extension/metamask-extension/work/i1-xxxxxx/metamask-extension/ui/contexts/assetPolling.tsx", … }
]}

made 1,800 fingerprints depend on the build directory. Worse, they also depended on timing. The wrapper can only record events when it runs in the main process (it needs this._module, which thread-loader workers do not have). thread-loader normally runs these loaders in worker processes, but when its worker pool is unavailable it silently falls back to running them in-process. On a fast machine the pool stays alive and nothing is ever recorded. On a slow 2-core CI runner the pool goes idle and gets disposed mid-build, and a timing-dependent subset of modules gets the statistics recorded:

  build 1:  assetPolling.tsx → buildMeta has __reactCompilerStatus__  (path i1-xxxxxx)
  build 2:  assetPolling.tsx → buildMeta has __reactCompilerStatus__  (path i2-xxxxxxxxxxxx)
  build 5:  assetPolling.tsx → no __reactCompilerStatus__ at all

This is why this one can only be seen on CI: on a laptop it is literally not there.

The fix

Store the events on buildInfo instead, webpack's drawer for "things that happened while building this module", which is not hashed, and record the filename relative to the project root. ReactCompilerPlugin reads from buildInfo now. The verbose report is unchanged.

-  const buildMeta = this._module?.buildMeta
+  const buildInfo = this._module?.buildInfo
   …
-          filename,
+          filename: rootContext ? relative(rootContext, filename) : filename,
   …
-        buildMeta[REACT_COMPILER_STATUS_KEY] = { events };
+        buildInfo[REACT_COMPILER_STATUS_KEY] = { events };

How we know it works

This branch, built unmodified at 20 different paths on the CI runners: 1 runtime.js and 1 whole-dist digest across all 20. Without this fix, the same 20 builds split 16 / 4.

✨ Files requiring CODEOWNER review ✨

Quality Gate failed

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

See analysis details on SonarQube Cloud