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

[digeomel]

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.

https://www.youtube.com/watch?v=B-lipaiZII8&t=215s

Enter the URL of the topic with the problem

https://angular.io/guide/deployment#inspect-the-bundles

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]

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]

@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]

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]

@geromegrignon is referring to that tweet: https://twitter.com/mgechev/status/1278338744077004801

[digeomel]

@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]

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.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}