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

Aberta
  • Algo errado?
#34,674 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
55/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
angular, typescript
Domínio
build-system

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
27k
Forks
11.8k
Merge médio
1d 3h
PRs com merge (30d)
271

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de angular/angular-cli

Todas as issues de angular/angular-cli

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.