refactor(@angular/build): optimize i18n locale polyfill data bundling per locale - #33921
Conversation
Sorry, something went wrong.
There was a problem hiding this comment.
Code Review
This pull request refactors the Angular locale data resolution and loading logic out of the esbuild plugin into reusable helper functions, and integrates them into the i18n inliner worker to inject locale data directly alongside locale insertion sites. Feedback on these changes highlights two main issues: first, appending the locale data script to every insertion site can cause duplicate injections and bundle bloat when multiple sites exist; second, silent catch blocks during file reads could lead to silent failures, and any I/O errors should instead be caught and reported.
Sorry, something went wrong.
… per locale Inject global Angular locale data scripts on-demand into each locale's polyfill bundle during inlining instead of bundling all active locale datasets into a single shared polyfill output file. The `loadLocaleData` utility resolves and caches `@angular/common/locales/global` data per locale. During inlining, `i18n-inliner-worker` injects the specific locale data script alongside `___NG_LOCALE_INSERT___` in the polyfill bundle. This eliminates cross-locale bundle bloat so users download only the exact locale data needed for their targeted locale.
|
This PR was merged into the repository. The changes were merged into the following branches:
|
Sorry, something went wrong.
Inject global Angular locale data scripts on-demand into each locale's polyfill bundle during inlining instead of bundling all active locale datasets into a single shared polyfill output file.
The loadLocaleData utility resolves and caches @angular/common/locales/global data per locale. During inlining, i18n-inliner-worker injects the specific locale data script alongside ___NG_LOCALE_INSERT___ in the polyfill bundle. This eliminates cross-locale bundle bloat so users download only the exact locale data needed for their targeted locale.