Why is webpack-bundle-analyzer strongly *not* recommended?

This issue has been tracked since 2023-01-30.

Describe the problem that you experienced

For a long time, developers have been using webpack-bundle-analyzer to analyze Angular app bundle sizes. Then, at some point (Angular 9?) it came to be that webpack-bundle-analyzer was strongly discouraged by the Angular team, but other than the video below, I cannot find any official Angular documentation about it.


Enter the URL of the topic with the problem


Describe what you were looking for in the documentation

I am looking into a clear explanation on why webpack-bundle-analyzer is strongly discouraged, in favor of source-map-explorer.

Describe the actions that led you to experience the problem

I'm working with a custom framework which still uses webpack-bundle-analyzer in Angular versions 14-15.
On top of that, there are plenty of articles still online on how to use webpack-bundle-analyzer with Angular apps. This causes confusion (assuming there are serious reasons why we shouldn't be using it).

Describe what you want to experience that would fix the problem

The link in the documentation mentioned above should clearly state that webpack-bundle-analyzer is not recommended, and state the reasons why.

Add a screenshot if that helps illustrate the problem

No response

If this problem caused an exception or error, please paste it here

No response

If the problem is browser-specific, please specify the device, OS, browser, and version

No response

Provide any additional information here in as much as detail as you can

No response

geromegrignon wrote this answer on 2023-01-30

You can find info here: https://gitlab.com/gitlab-org/gitlab-foss/-/issues/33497

About the documentation, I disagree about changes: the goal should be to convey good practices only.
It should focus on what's encouraged.

digeomel wrote this answer on 2023-01-30

@geromegrignon thanks for the link, but this is not official, and I don't think a tool should be strongly discouraged for not being "perfectly accurate". If that's the only problem with it, we might as well keep using it.

geromegrignon wrote this answer on 2023-01-30

This content was shared in the past by Minko Gechev, so while not official content, it means the Angular team shares these thoughts.

That's up to you to choose the tool you want, I would have some concerns about bundle inspection by using a tool known as not being 'perfectly accurate' when there is an alternative.

JeanMeche wrote this answer on 2023-01-30
digeomel wrote this answer on 2023-01-30

@geromegrignon @JeanMeche to be clear, if it were up to me, I'd be using source-map-explorer (and I did, in previous projects).
The problem is, convincing a team that's used to webpack-bundle-analyzer and are not convinced that switching tools (which will involve some extra integration work for them) will provide any clear benefit.
Because ultimately, you use a bundle analyzer to see what packages are eating up space for no reason and eliminate them, you don't care about whether the size reports are off by a few kb.

alan-agius4 wrote this answer on 2023-01-31

You are free to use webpack-bundle-analyzer. But it’s important to point out that by using a custom webpack configuration you are charting unsupported territory.

source-map-explorer has a number of advantages:

  • it does not need to be plugged into the build system and therefore is bundler agnostic
  • since it does not plug into the build it does not impact build times.
  • as mentioned in the article above, It’s more accurate.

Historically, the CLI did some optmizations outside of webpack context which caused the webpack-bundle-analysed to generate reports on not fully optimized bundles.

More Details About Repo
Owner Name angular
Repo Name angular
Full Name angular/angular
Language TypeScript
Created Date 2014-09-18
Updated Date 2023-03-21
Star Count 87006
Watcher Count 3028
Fork Count 23170
Issue Count 1418


Issue Title Created Date Updated Date