i18n causes esbuild chunks to be cache-busted on each deploy
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 48/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Calme
- Stack technique
- angular, typescript
- Domaine
- build-system, localization, performance
Piste de recherche
Commencez par la reproduction minimale liée, en utilisant angular.json, src/locale/messages.fr.xlf et le point d’entrée ng build --localize. Comparez les bundles générés et leurs commentaires i18n avant et après la modification de la traduction, puis retracez le chemin de build de la localisation. C’est terminé lorsque le contenu des chunks inchangés conserve des noms de fichiers stables entre les builds et que la sortie localisée reste correcte.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Command
build
Is this a regression?
- Yes, this behavior used to work in the previous version
The previous version in which this bug was not present was
Webpack builder
Description
Turning on esbuild is causing us to experience a large increase in the number of static requests served to our users (+9B requests/mo / +60% increase), leading to a substantial impact on our CDN bill.
Each spike in the graph above aligns with a deploy (no deploys on weekends), indicating that all assets appear to be cache-busted with each new build (whereas in practice only a fraction of the code is updated between versions).
Upon investigating where this could come from, I noticed that chunks with identical content between two build versions have different filename hashes, i.e., chunk-ASRRVFTX.js in the first one and chunk-MO3N5ZQM.js in the second one:
If you look carefully, you can notice that the chunk contents are not exactly identical—they differ by the value of the i18n: comment. Looking into it, that i18n hash is the same for all the chunks (in any locale) across a build and appears to be a SHA256 of all the localized dictionaries.
Since at least a couple of strings are going to change across builds (we have ~14k strings in the app), this effectively means that the entire app is cache-busted on each deploy, leading to increased infrastructure costs and degraded client-side performance.
Minimal Reproduction
Minimal repro is available here: https://github.com/laurentgoudet/angular-i18n-esbuild-bug
Steps I performed:
ng newng add @angular/localize- Configured an
frlocale inangular.json - Added some string in
app.ts - Ran
ng extract-i18nto extract the dictionary - Copied
messages.xlftosrc/locale/messages.fr.xlf - Ran
ng build --localizeto run the localized build
ng build --localize
Initial chunk files | Names | Raw size | Estimated transfer size
main-BGVPYDPI.js | main | 221.57 kB | 61.67 kB
polyfills-25EJAOGH.js | polyfills | 36.97 kB | 12.41 kB
styles-5INURTSO.css | styles | 0 bytes | 0 bytes
| Initial total | 258.54 kB | 74.08 kB
Application bundle generation complete. [1.794 seconds]
- Observed that
i18n:hash is the same betweenpolyfills-<foo>.js&main-<foo>.jsbundles in bothen-US&fr
$ rg -l i18n:cf2ec5733a24b255a5f4c5407a5cd5747f51614f533bf44f15ae320960b64048 dist
dist/test-esbuild-i18n/browser/en-US/polyfills-PJEY6MCR.js
dist/test-esbuild-i18n/browser/fr/polyfills-PJEY6MCR.js
dist/test-esbuild-i18n/browser/en-US/main-YXPGXXTL.js
dist/test-esbuild-i18n/browser/fr/main-YXPGXXTL.js
-
Add a translation for in the
frdictionary (src/locale/messages.fr.xlf) -
Run
ng build --localizeagain -
Observe that the filename hashes have changed
ng build --localize
Initial chunk files | Names | Raw size | Estimated transfer size
main-YXPGXXTL.js | main | 221.57 kB | 61.67 kB
polyfills-PJEY6MCR.js | polyfills | 36.97 kB | 12.45 kB
styles-5INURTSO.css | styles | 0 bytes | 0 bytes
| Initial total | 258.54 kB | 74.13 kB
Application bundle generation complete. [1.426 seconds]
Exception or Error
Your Environment
ng version
_ _ ____ _ ___
/ \ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _|
/ △ \ | '_ \ / _` | | | | |/ _` | '__| | | | | | |
/ ___ \| | | | (_| | |_| | | (_| | | | |___| |___ | |
/_/ \_\_| |_|\__, |\__,_|_|\__,_|_| \____|_____|___|
|___/
Angular CLI: 20.0.5
Node: 22.15.0
Package Manager: npm 10.9.2
OS: darwin arm64
Angular: 20.0.6
... common, compiler, compiler-cli, core, forms, localize
... platform-browser, router
Package Version
------------------------------------------------------
@angular-devkit/architect 0.2000.5
@angular-devkit/core 20.0.5
@angular-devkit/schematics 20.0.5
@angular/build 20.0.5
@angular/cli 20.0.5
@schematics/angular 20.0.5
rxjs 7.8.2
typescript 5.8.3
zone.js 0.15.1
Anything else relevant?
No response
- Langage dominant
- TypeScript
- Étoiles
- 27k
- Forks
- 11.8k
- Merge moyen
- 16 h 35 min
- PR mergées (30 j)
- 176
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de angular/angular-cli
-
Can't use an array of hostnames in --allowedHosts cli parameter in @angular/build:dev-server Ouvertearea: @angular/build gemini-triaged
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
angular/angular-cli#33955 ·
-
area: @angular/cli gemini-triaged
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
angular/angular-cli#33055 · 1 commentaire · 3 réactions ·
-
unit-test: with --coverage, a setup file's hooks reach only the first spec file of each worker Ouvertearea: @angular/build gemini-triaged
Difficulté 4/5 3-5 jours Accessibilité débutants 72/100
angular/angular-cli#34137 ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34131 · 1 personne assignée ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34130 · 1 personne assignée ·
Toutes les issues de angular/angular-cli
Issues similaires
-
S: triage
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 90/100
snapshot-labs/stamp#666 ·
-
fix(api): prevent leaderboard SSE heartbeat from starting after disconnect during initial load Ouvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
GauravKarakoti/SecureFlow#1070 · 1 commentaire ·
-
feature:Languages/Translations good first issue ready Web
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
digitalfabrik/integreat-app#4394 ·