Huh, never heard of Brotli before 😄 . Awesome to learn new things!

@th0r should be able to answer with any suggestions and feedback, when he's got time. I'd like to at least see a proof-of-concept of this Brotli support if possible☺️

Never heard of Brotli as well. The only concern I have is the increasing of analyze time. Agree with@valscion here - it would be nice to see a proof-of-concept PR and comparison of analyze times with and without it.

It might be possible to add brotli support if it would be calculated only when some CLI or plugin option would be there. That way it would not increase analyze time for those who don't yet care about Brotli.

👍

Hi guys, here there is the PR for Brotli support. It is working without problems on my setup. I couldn't include an opt-in option for the feature.

Here is a screenshot on how this looks:

Neat! I think it'll be necessary to have an opt-in somehow, but currently it might require some architectural changes. Large changes would cause difficult merge conflicts with#97, though — I hope I could get that finished some day 😕

I hope you're OK with using the Brotli support from your branch? It's a bit unlikely that we'll want to calculate these sizes by default as brotli isn't that widely used yet

If this does get implemented, please can the brotli related dependencies not be added todependencies - to avoid issues like those insiddharthkp/bundlesize#202. (eg check for the dependencies at runtime and if not found and "brotli mode" enabled, output a suitable message.)

Re Brotli itself, we happily use it on several production sites, however I'm not sure of the value of displaying brotli sizes in the analyzer, given:
(a) brotli compression is much slower so would have much more of an impact on how long this plugin takes to run,
(b) whilst not entirely linear, one would presume the size ratios of the bundle for gzip vs brotli would be close enough that it wouldn't really affect any decisions based on the results (eg deciding what changes to make tosplitChunks settings).

If this does get implemented, please can the brotli related dependencies not be added to dependencies - to avoid issues like those insiddharthkp/bundlesize#202. (eg check for the dependencies at runtime and if not found and "brotli mode" enabled, output a suitable message.)

Huh, thanks for the pointer :)

That should be easier now that native Brotli support (https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V11.md#notable-changes) landed in Node.

Something new to this?

#113 (comment)

The only concern I have is the increasing of analyze time. Agree with@valscion here - it would be nice to see a proof-of-concept PR and comparison of analyze times with and without it.

#113 (comment)

It might be possible to add brotli support if it would be calculated only when some CLI or plugin option would be there. That way it would not increase analyze time for those who don't yet care about Brotli.

#114 (comment)

The crux is that we don't want this to increase analyze time, and this feature would have to be opt-in. Currently it might require some architectural changes, though, so it isn't that easy to do.

When is this getting merged ?

When someone who wants brotli size support does what we've described that needs to be done. See the comment right above yours.

I have the use-case that the pipeline analysis doesn't usegzip at all, it relies completely onbrotli. It would be great if it had the ability to choose one of them.

Brotli is the standard web compression method now (at least for anyone not supporting IE11), is it possible to revisit this?