I work on Lighthouse, and a few years ago I developed the audit for detecting likely unnecessary polyfills and reporting their cost to developers. The goal of that audit is to inform developers when their website is polyfilling widely-supported JS features; the idea being that very few websites need to support truly legacy browsers (and in fact, many sites that include such polyfills don't even load in legacy browsers due to inconsistent tooling).

This Lighthouse audit has been around for a few years, and recently I updated it (no need to dig into this, it's not related to my proposal).

I'd like to suggest a small change to core-js to greatly improve the accuracy of this audit.

Today the audit detects polyfills in two ways:

1. grepping the scripts of the website for evidence of polyfils emitted by core-js
2. if source maps are present, looks for specific module files

Many sites don't deploy source maps, so option 1 is important to do well. However, the grepping solution is clunky, expensive to run, and prone to false positives. It's tough to correctly identify all possible polyfills, as it relies on detecting code that has gone through any arbitrary bundler/minifier/etc.

My proposal is to add to the shared global (window['__core-js_shared__']) - for each versions entry, provide the list of modules that core-js decided to include (as given by core-js-compat). That way, even without source maps, it can easily be determined what polyfills core-js added to the page.

If this sounds good to you, I'm happy to implement this myself.