Allow whitelist and blacklist options for runtime transformer definitions (T6904)

[babel-bot]

Issue originally made by @guybedford

Description

It would be nice to add a custom options whitelist and blacklist to the runtime transformer something like:

plugins: [['transform-runtime', { exclude: ['Promise', 'Array.*', 'Object.defineProperty'] }]]

Or an opt-in-only whitelist:

plugins: [['transform-runtime', { include: ['Object.assign', 'String.*', 'Math.*'] }]]

The specific use case that came up for me now was excluding the Promise polyfill in particular since SystemJS by default has a polyfill present already.

The nice thing is this would enable the creation of runtime transformer presets which can be based on various engine support baselines.

[babel-bot]

Comment originally made by @guybedford

Actually the polyfill: false option seems to cover the majority use case here perfectly.

So perhaps just to document the above option with a note in the readme?

Otherwise happy to close this.

[babel-bot]

Comment originally made by @guybedford

There is another case that needs an opt-out here and that is the typeof operator.

Currently with the babel-runtime transformer the typeof operator is always replaced with the reference to the runtime library. That in turn relies on the Core-js Symbol polyfill, which then pulls in a whole bunch of stuff. Ideally this loading cascade shouldn't happen when setting polyfill: false?

The babelHelpers global doesn't seem to rely on the Symbol polyfill so perhaps the typeof modular build in babel-runtime doesn't either? Otherwise just disabling the typeof replacement entirely would be useful here.

[babel-bot]

Comment originally made by @schmod

There's some discussion around a related issue in [[ https://github.com/webpack/webpack/issues/2873#issuecomment-241791521 | webpack#2873 ]].

Basically, I'm finding it difficult to understand when it's appropriate/recommended to use babel-polyfill vs transform-runtime vs external-helpers.

There's no documentation that describes what polyfill: false actually does, or what the recommended solution is for efficiently transpiling browser-based applications.

Weirder still, as @guybedford mentioned, the helpers patched in by transform-runtime seem to use a different implementation (or at least different dependencies) compared to what is provided by external-helpers.

Many of the core-js implementations (particularly of ES5 features) are also unnecessary in modern environments -- things like Object.keys() have been natively-supported since IE9.

I've also noticed that Rollup's developers seem to have encountered many of the same frustrations, as [[ https://github.com/rollup/rollup-plugin-babel/blob/master/src/index.js#L36 | rollup-plugin-babel ]] provides [[ https://github.com/rollup/rollup-plugin-babel/blob/master/src/index.js#L36 | its own implementation]] of external-helpers and discourages users from using transform-runtime.

---

Formulating this as a story:

As a browser-based developer, I would like to be able to compile an application that:

• Includes exactly one implementation of each Babel helper required by my application and its dependencies.
• Patches in the core-js implementations of the ES2016 built-ins used by my application and its dependencies that aren't commonly available in modern browsers.
• Allows me to provide my own definition of "modern browser."

In the above requirements, it is assumed that:

• The global scope is never polluted.
• I do not need to modify the source code of my application.
• My application's library dependencies can take advantage of the same optimizations (provided that they are written in ES6)
• The transformed application only depends upon the exact set of core-js shims and babel helpers that are necessary at runtime.
• I have the ability to consolidate helpers without applying core-js transformations, and vice-versa.

Satisfying these criteria requires implicitly requires us to resolve T6834 (or to provide convenient hooks for tools like Rollup and Webpack to provide their own implementations of module-centric helpers)

[hzoo]

Moved some duplicate/similar issues into this. We should definetely do it.

At the minimum we can expose a import 'babel-polyfill/es2015' etc per year, but doing individual ones as options could work as well.

[missingtrailingcomma]

Idea: instead of specifying what syntaxes to be transformed, what about specifying what is the targeting js version?

So it's like the preset specifies a higher bound of syntaxes babel is support for transforming, and the targeting js version specifies a lower bound.

For example, say I am writing es2016 code (no async etc.), and I am targeting platform which have full support for es2015. Then Object.assign() is not transformed while 2**3 is transformed.

[nicolo-ribaudo]

This is now supported in the new babel-polyfills repository. You can configure Babel like this:

{
  "plugins": [
    ["polyfill-corejs3", {
      "method": "usage-pure",
      "exclude": ["es.promise"]
    }]
  ]
}

Or, if you need more advanced filters, you can use the shouldInjectPolyfill option.