large-javascript-libraries rework proposal

[connorjclark]

We moved large-javascript-libraries out of the default config after receiving some negative feedback from developers concerned about Google choosing winners based on an unclear criteria. I collected some potential action items to fix this audit incrementally, but instead here I want to propose an entirely different approach.

• Keep as diagnostic audit (don't upgrade to an opportunity)
• Require source maps so we know the actual size and can detect packages without js-library-detector
• Show all packages larger than 200 kB (uncompressed)
• Link to https://bundlephobia.com/result?p=
• Change title to Evaluate if large libraries on this page are necessary or have smaller alternatives

EDIT: TIL https://packagephobia.com/result?p=lighthouse

[ljharb]

I find this to be much less objectionable than the original approach, so thanks for listening to feedback.

I find bundlephobia to encourage very biased inferences, as the "bundle size" impact of a package simply can't be known outside of the entire app in which it lives - for example, if a transitive dependency is large, but it's used by half of your app, the size really isn't a meaningful factor in making a decision - or, if you've configured your bundler settings to optimize away packages that you know your target platforms you don't need (eg, replacing a polyfill package with a known-present or known-shimmed native implementation), then the impact of adding a new package might become negligible.

[connorjclark]

We are considering not reintroducing this audit, and instead relying on the planned "Large Modules" view of the soon-to-release Treemap App. In the table view in that mode, we can possibly link to external sites for alternative suggestions.

[connorjclark]

Small update: we aren't even doing a "Large Modules" view in treemap app, since the size of the nodes itself does the same function...

Just need to remove old code to mark this closed.