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

Abierto
  • ¿Algo no está bien?
#34,674 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
angular, typescript
Área
build-system

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
27k
Forks
11.8k
Merge medio
1 d 3 h
PR fusionados (30 d)
271

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de angular/angular-cli

Todos los issues de angular/angular-cli

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.