"useBuiltIns: usage" for node_modules without transpiling

[fabb]

Feature Request

The Problem

"useBuiltIns: usage" of preset-env is a genius idea to only include the polyfills really needed. Unfortunately it does not work for node_modules. We could whitelist node_modules to be babel transpiled so polyfills get inserted for these as well, but this might not be desired for several reasons:

1. It might break the code of some node_modules
2. It increases compile time

Proposed Solution

preset-env could get a new option to follow node_module imports in transpiled files, and analyze the imported file for polyfills needed, and insert necessary polyfill imports into the originally transpiled file. It might be that a new webpack-specific plugin would be needed to understand and follow imports.

In

a.js

import somemodule from "somemodule";

node_modules/somemodule/index.js

var a = new Promise();

Out

a.js

import "core-js/modules/es6.promise";
import somemodule from "somemodule";

node_modules/somemodule/index.js does not get modified.

Of course some cache will be needed to not analyze the same node_modules over and over again, maybe coupled to the version in package-lock.json, and only disabled for npm linked modules.

Alternatives Considered

1. Whitelist node_modules to be babel transpiled: not ideal, might break node_module code, compile time increase
2. Include all polyfills from core-js: unnecessary bloat
3. Manually maintain a custom core-js polyfill set: bad maintenance in bigger project, all polyfills get loaded at once instead as-needed taking advantage of webpack or another bundler (like useBuiltIns: usage is able to)
4. For browsers not supporting es6 modules, include full core-js, for newer browsers, do not polyfill: there are some polyfills and fixes still necessary for newer browsers
5. Use a service like polyfill.io: Every browser needs to make an additional request, even when doing SSR, even for newer browsers unnecessary bloat since the polyfill service does not know which polyfills the application needs
6. Polyfill directly in node_modules: this is a bad idea, because it would include the same polyfill several times in different node_modules

Teachability, Documentation, Adoption, Migration Strategy

Since it is a purely additive feature, users can gradually opt in and replace their old polyfilling strategy with this one. The new option could be called useBuiltIns: 'usage-node_modules' or similar.

[babel-bot]

Hey @fabb! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[zloirock]

Some my related thoughts here https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md#better-optimization-of-polyfill-loading

[deckar01]

I ran into this today. Due to #8932, the work around for this seems to be using any needed features in the main script to trigger usage detection.

export async function _polyfillPromise() {}

[nyngwang]

Let me link this issue to my discussion: #14433

[nicolo-ribaudo]

You can now compile your node_modules enabling only babel-plugin-polyfill-corejs3, rather than enabling all the preset-env transforms.

https://github.com/babel/babel-polyfills