Implement new transform-runtime protocol for runtime package name #160
Conversation
| @@ -22,7 +24,7 @@ type Options = { | |||
| entryInjectRegenerator: boolean; | |||
| }; | |||
| "#__secret_key__@babel/runtime__compatibility": void | { | |||
| useBabelRuntime: string; | |||
| useBabelRuntime: boolean; | |||
There was a problem hiding this comment.
Is this a breaking change? If so this PR should be landed in a new major.
There was a problem hiding this comment.
Yes, but these packages are still at 0.x (so breaking changes are in minor releases)
There was a problem hiding this comment.
Yes, 0.x -> 0.x+1 is what I mean for a new major.
| file.get("runtimeHelpersModuleName") !== runtimeName | ||
| ) { | ||
| console.warn( | ||
| `Two different polyfill providers are trying to define two` + |
There was a problem hiding this comment.
Can runtimeHelpersModuleName also record who defined it? So we can simply say that the current provider babel-plugin-polyfill-foo conflicts with another provider babel-plugin-polyfill-bar, please remove one of them. Otherwise users have to dive into the implementation detail and dig about who defined runtimeHelpersModuleName, which could be very frustrating.
|
@JLHwung @liuxingbaoyu Any opinion regarding this? |
The goal of this new API is that any polyfill provider can specify their own polyfilled version of
@babel/runtime(such as@babel/runtime-corejs3), instead of hard-coding@babel/runtime,@babel/runtime-corejs2and@babel/runtime-corejs3in@babel/plugin-transform-runtime.This is done by returning a
runtimeName: stringproperty in the polyfill provider result object, which will be picked up by@babel/plugin-transform-runtimewhen injecting helpers.See babel/babel#15531 for the other part of this change. This PR needs to land first.