Implement new transform-runtime protocol for runtime package name#160
Conversation
| }; | ||
| "#__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? |
JLHwung
left a comment
There was a problem hiding this comment.
I don't have further comments, the changes look good to me.
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.