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

Aperta
#34,674 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
angular, typescript
Ambito
build-system

Direzione di ricerca

Start by tracing how the Angular build builder adds debug IDs to esbuild-named main and polyfills files, and compare that with the chunk optimizer fix in #34583. Use the reproduction steps to build with source maps and subresource integrity enabled, then check whether changed JavaScript bytes receive changed filenames and the generated index.html digests match. Done means the reported cache and SRI mismatch is reproduced and fixed for these files.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: @angular/build
Command

build

Is this a regression?

Yes. It started with the debug IDs in 22.1.0.

Description

Follow-up to #34574.

The builder names polyfills-<hash>.js and main-<hash>.js first. Then it adds a //# debugId=<id> line to the file. It computes <id> from the source map after it rewrites the map to add x_google_ignoreList. The file name does not cover that line.

So when a builder release writes the source map differently, the JS bytes change and the file name stays the same. 22.1.8 did that. Commit 5a0d226b7c moved x_google_ignoreList to the start of the map.

With subresourceIntegrity, the new index.html pins the new bytes. A CDN or browser cache that kept the old file under the same URL serves the old bytes, and the browser blocks the script. This happened to us in production with polyfills-<hash>.js.

#34583 fixed this for the chunks of the chunk optimizer. It does not cover files that esbuild names, such as main and polyfills. 22.2.6 still computes their debug ID from the rewritten map.

Minimal Reproduction
npx @angular/[email protected] new repro --defaults --ssr=false
cd repro
npm install zone.js
npm install -D @angular/[email protected]
npx ng config projects.repro.architect.build.options.polyfills '["zone.js"]'
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.1.6
npm install -D @angular/[email protected]
npx ng build && mv dist/repro/browser ../build-22.1.8

Both builds write polyfills-QWJLBG44.js and main-HHND32NM.js. In each file, only the //# debugId= line differs:

polyfills-QWJLBG44.js
  build-22.1.6: //# debugId=d932f97d-b667-5462-b3b7-b328a1ce7f5a
  build-22.1.8: //# debugId=81c8766a-7d41-50fd-ac6d-16c3c4ed6358
main-HHND32NM.js
  build-22.1.6: //# debugId=e3a30145-1442-57c2-96a7-a88f9bf43b0a
  build-22.1.8: //# debugId=50dd2d3c-f1e3-5224-9587-43f24f562421

The two index.html files pin different hashes for the same URLs. For both files, the two source maps have the same content in a different key order.

Exception or Error
Failed to find a valid digest in the 'integrity' attribute for resource 'https://example.com/polyfills-JTOAPWZJ.js' with computed SHA-384 integrity '...'. The resource has been blocked.
Your Environment
Angular CLI: 22.1.8
@angular/build: 22.1.6, then 22.1.8
@angular/core: 22.2.5
zone.js: 0.16.3
Node: 24.17.0
OS: macOS
Anything else relevant?

Expected: when the bytes of a hashed file change, its name changes too.

A possible fix is to compute the debug ID from the JS before the builder adds the debug ID line, not from the rewritten map. The file name already covers the JS.

Lingua principale
TypeScript
Stelle
27k
Fork
11.8k
Merge medio
1g 3h
PR unite (30g)
271

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di angular/angular-cli

Tutte le issue di angular/angular-cli

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.