Debug ID changes the bytes of polyfills and main but not their file names, so cached files fail the SRI check #34674

Activity

1. angular-robot

   added

   area: @angular/build

   on Nov 8, 2026
2. angular-robot

   added this to the needsTriage milestone on Nov 8, 2026
3. jsaguet

   changed the title [-]Debug ID changes the bytes of main and polyfills but not their file names, so cached files fail the SRI check[/-] [+]Debug ID changes the bytes of polyfills and main but not their file names, so cached files fail the SRI check[/+] on Nov 8, 2026
4. jsaguet commented on Nov 8, 2026

   

   jsaguet

   on Nov 8, 2026

   ContributorAuthor

   More actions

   The same symptom has a second cause: the entry file of the chunk optimizer. The debug ID fix above does not fix it.

   The chunk optimizer runs when an app has 3 or more lazy chunks. It renames the lazy chunks, and main imports them by name. But the optimizer passes chunkFileNames and no entryFileNames, so main keeps the name that esbuild gave it.

   So when a builder release changes how the optimizer names chunks, the bytes of main change and its name stays the same. 22.2.6 did that with #34583.

   npx @angular/cli@22.2.5 new repro --defaults --ssr=false
   cd repro
   npm install -D @angular/build@22.2.5
   npx ng generate component a
   npx ng generate component b
   npx ng generate component c
   cat > src/app/app.routes.ts <<'EOF'
   import { Routes } from '@angular/router';
   
   export const routes: Routes = [
     { path: 'a', loadComponent: () => import('./a/a').then((m) => m.A) },
     { path: 'b', loadComponent: () => import('./b/b').then((m) => m.B) },
     { path: 'c', loadComponent: () => import('./c/c').then((m) => m.C) },
   ];
   EOF
   npx ng config projects.repro.architect.build.configurations.production.sourceMap true
   npx ng config projects.repro.architect.build.configurations.production.subresourceIntegrity true
   npx ng build && mv dist/repro/browser ../build-22.2.5
   npm install -D @angular/build@22.2.6
   npx ng build && mv dist/repro/browser ../build-22.2.6

   Both builds write main-5H54S2WB.js, and the two index.html files pin different hashes for it. The only difference in the file is the names of the chunks it imports:

   build-22.2.5: chunk-jbVvGIzd.js chunk-BldQ8CJu.js chunk-BsxYmvae.js
   build-22.2.6: chunk-Dn-U95iY.js chunk-Da40IlVd.js chunk-DZObh1Dd.js
   

   The debug ID and the source map of main are the same in both builds.

   A possible fix is to give the entry a content hash with entryFileNames, the same way as chunkFileNames, and to update index.html with the new name. A fix that computes every file name from its final bytes would cover both causes.
5. jsaguet commented on Nov 8, 2026

   

   jsaguet

   on Nov 8, 2026

   ContributorAuthor

   More actions

   I looked at how to fix both causes. The fix for the second cause is small. The fix for the first cause has a trade-off that a maintainer should decide.

   The rule I want to keep is that when the bytes of a hashed file change, its name changes too. That rule must also hold on the upgrade to the release that contains the fix.

   Second cause: the entry file of the chunk optimizer

   The fix passes entryFileNames to the three generate() calls in chunk-optimizer.ts, so main gets a content hash when bundles are hashed. initialFiles then uses the new name. With outputHashing: none, the file stays main.js.

   When the optimizer runs, the name of main can now contain lowercase letters, _, and -, as the names of the lazy chunks already do.

   First cause: the debug ID

   The builder adds the debug ID line after esbuild picks the file name. If the builder computes the ID in a new way, the bytes of each file change and its name stays the same. The release that fixes this bug would therefore cause the same SRI failure one more time. It would affect apps that use script source maps and SRI and still have the old files in a cache.

   I see these options:

   1. Compute the debug ID from the file name and the JS. A later rewrite of the source map can no longer change the JS. The upgrade still breaks the rule once, so the release would need a note that tells users to purge cached JS.
   2. Do option 1 and force a one-time rename. This needs a version comment in the esbuild bundles and a constant in augmentChunkHash. The upgrade is safe, but the bundles carry a comment that exists only to change a hash. I don't like this option.
   3. Keep the current debug ID and name the files from their final bytes. This is the option I prefer.

   Option 3 adds a step after injectDebugIds, only when bundles are hashed and script source maps are on. The step hashes each JS file with the names of the other output files replaced by a placeholder. It includes the hashes of the files that the JS file can reach through imports, as Rollup does to handle import cycles. It then renames the files and updates those names in the JS and the source maps. initialFiles and the metafile get the new names, so the index HTML, SRI, the SSR manifest, and the service worker use them.

   With option 3, every file with a debug ID gets a new name once, on the upgrade. After that, any change to the bytes of those files changes the name, whatever the cause. The cost is more code, because the builder would rewrite file names inside generated code. Each locale also needs its own copy of initialFiles and the metafile, and the build stats table must print the final names.

   Keeping the current debug ID without option 3 avoids the upgrade problem, but the bug comes back the next time the builder writes the source map differently.

   Would you accept a rename step like option 3 in the application builder? I have not built it yet. If you would not, which other option do you prefer? I can open a PR for the second cause now and a PR for the first cause once you pick a direction.