Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Creating unnecessary excessive chunks

Offen
#27,715 43 Kommentare 69 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
38/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
angular, typescript

Rechercherichtung

Führe zunächst build in der verknüpften ng-esbuild-demo-Reproduktion aus und vergleiche die hier beschriebenen Listen der initialen und Lazy-Chunks. Lies den verknüpften Abschnitt zur esbuild-Code-Splitting-Architektur und verfolge anschließend die Build-Integration der Angular CLI, um herauszufinden, wo statisch erforderliche gemeinsame Module zu separaten initialen Chunks werden. Als erledigt gilt, wenn erforderlicher gemeinsamer Code keine unnötigen initialen Requests mehr erzeugt, ohne ungenutzten Code in das initiale Bundle zu übernehmen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

angular/build:application area: @angular/build freq2: medium severity4: memory/performance
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

No response

Description

Disclaimer

This is not really a bug, as even if it worked differently with webpack, for esbuild this is normal. However, since the default bundler is now esbuild some would consider this a regression.

Required chunks references in dynamic imported code get split in to separate chunks

When splitting code, esbuild does not seems to properly take into account what is already statically imported (thus "required") and does not need to be split into a separate chunk.

To illustrate this lets consider an example where we have the following 5 standalone components:

  • AppComponent (The root component which is not lazy loaded)
  • Feature1Component (A feature component lazy loaded via a dynamic import in the router)
  • Feature21Component (A feature component lazy loaded via a dynamic import in the router)
  • Ui1Component (A UI component imported statically, like a button)
  • Ui2Component (A UI component imported statically, like a button)
Chunks without Shared Components

If the AppComponent has a RouterOutlet which has separate paths Feature1Component and Feature21Component it will generate a chunk for the code shared between these components (lets call it Common Chunk).

In this case the build output is:

Initial chunk files Names
chunk-YIKH6UD4.js - ("common")
main-V6UA4PHT.js main
Lazy chunk files Names
feature-1.component-AQEBZKLJ.js feature-1-component
feature-2.component-EH7EGWEP.js feature-2-component

And if Feature1Component imports Ui1Component and Feature21Component imports Ui2Component then code from Ui1Component will be bundle in Feature1Component and the code from Ui2Component will be bundle in Feature2Component.

Chunks with Shared Components

However, if the AppComponent also imports Ui1Component and Ui2Component this code is now shared and will be split into separate chunks.

Thus the build output will now be:

Initial chunk files Names
chunk-YIKH6UD4.js - ("common")
main-V6UA4PHT.js main
chunk-WKA4CZR7.js - ("ui-1-component")
chunk-XCJUHD2B.js - ("ui-2-component")
Lazy chunk files Names
feature-1.component-AQEBZKLJ.js feature-1-component
feature-2.component-EH7EGWEP.js feature-2-component

The issue is that Ui1Component and Ui2Component are now statically imported in the AppComponent, and therefore belong in this common chunk. These chunks are statically imported in the "common" chunk and required for the application to bootstrap but are downloaded separately.

As they are always downloaded, splitting them does not seems to have a benefit, when Feature1Component or Feature2Component imports them, the request is cached and it should not make a difference if it over imports.

However, splitting them does have a downside, it increases the load time. Even tho in this example the consequences of a couple of extra chunks is meaningless in larger apps the consequence is very real.

If the application produces 100 or 200 initial chunks this will have a significant impact on the initial load time and LCP.

image

Even tho the a modern browser using http3 or http2 uses multiplexing it will still have an significant overhead downloading so many small chunks. We are currently calling this the chunk gap:

image

Additionally this issue will have a larger impact on older and slower devices.

Additional example of performance impact:

Avoiding Code Splitting Shared Code

It seems possible to avoid additional chunking in some cases by using barrel files.

For example if we create a barrel file that exports both Ui1Component and Ui2Component and only import them via that barrel file we are able to force esbuild to place the shared code into the "common" chunk.

So using:

// ./ui/index.ts

export * from './ui-1.component';
export * from './ui-2.component';

The build output will now be:

Initial chunk files Names
chunk-YIKH6UD4.js - ("common")
main-V6UA4PHT.js main
Lazy chunk files Names
feature-1.component-AQEBZKLJ.js feature-1-component
feature-2.component-EH7EGWEP.js feature-2-component

Note

In esbuild architecture documentation it explains that:

code splitting is implemented as an advanced form of tree shaking.

This means that doing so will partially optout of tree shaking.

For example if we add a Ui3Component and a Feature3Component.

And we add the Ui3Component to the barrel file:

// ./ui/index.ts

export * from './ui-1.component';
export * from './ui-2.component';
export * from './ui-3.component';

If the Ui3Component is never imported anywhere it will not increase the initial bundle.

However, if we reference the Ui3Component in Feature3Component (loading the Feature3Component in a lazy route), this will increase the initial bundle even if Ui3Component is not used in the AppComponent.

Minimal Reproduction

https://github.com/ChristopherPHolder/ng-esbuild-demo

Exception or Error
Shared Code Required in a root component or a root node of the node graph is bundle together.
Your Environment
Angular CLI: 17.3.5        
Node: 20.11.1              
Package Manager: npm 10.2.4
OS: win32 x64

Angular: 17.3.5
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1703.5
@angular-devkit/build-angular   17.3.5
@angular-devkit/core            17.3.5
@angular-devkit/schematics      17.3.5
@schematics/angular             17.3.5
ng-packagr                      17.3.0
rxjs                            7.8.1
typescript                      5.4.5
zone.js                         0.14.4
Anything else relevant?

No response

Vorherrschende Sprache
TypeScript
Sterne
27k
Forks
11.8k
Ø Merge
17 Std. 25 Min.
Gemergte PRs (30 T.)
183

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus angular/angular-cli

Alle Issues in angular/angular-cli

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.