Creating unnecessary excessive chunks
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 38/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- angular, typescript
调研方向
首先在链接的 ng-esbuild-demo 复现项目中运行 build,并比较此处描述的初始 chunk 和惰性 chunk 列表。阅读链接的 esbuild 代码拆分架构部分,然后跟踪 Angular CLI 的构建集成,找出静态要求的共享模块变成独立初始 chunk 的位置。完成的标准是,必需的共享代码不再产生不必要的初始请求,同时不会将未使用的代码带入初始 bundle。
由索引模型根据 Issue 内容生成。
描述
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.
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:
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
- 主要语言
- TypeScript
- 星标
- 27k
- 派生
- 11.8k
- 平均合并
- 16 小时 35 分钟
- 30 天内合并 PR
- 176
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
angular/angular-cli 的其他 Issue
-
area: @angular/build gemini-triaged
难度 2/5 1-3 小时 新手友好度 74/100
angular/angular-cli#33955 ·
-
area: @angular/cli gemini-triaged
难度 2/5 1-3 小时 新手友好度 72/100
angular/angular-cli#33055 · 1 条评论 · 3 个 reaction ·
-
area: @angular/build gemini-triaged
难度 4/5 3-5 天 新手友好度 72/100
angular/angular-cli#34137 ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34131 · 已指派 1 人 ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34130 · 已指派 1 人 ·
查看 angular/angular-cli 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 74/100
ontola/atomic-server#1625 ·
-
bug
难度 2/5 1-3 小时 新手友好度 70/100
melgarafael/DeskcommCRM#1451 ·
-
难度 1/5 1 小时以内 新手友好度 82/100
-
bug via-triage
难度 2/5 1-3 小时 新手友好度 78/100
-
bot:ai-assisted component:compact-js status:untriaged
难度 2/5 1-3 小时 新手友好度 84/100
midnightntwrk/midnight-sdk#403 ·