Clarifications regarding migration and backwards compatibility
- Dominant language
- TypeScript
- Stars
- 357
- Forks
- 62
- PR merge metrics
- No merged PRs in 30d
Description
Hi guys! Thank you for all your great work here, I really think `babel-polyfills` is the good path to follow. It just took me some time to find it.
Yesterday I started the migration in one library from a `@babel/preset-env`/`@babel/plugin-transform-runtime` setup. I carefully read all your notes and some of the source code involved, however, I wrote down some doubts that I would like to clarify before making my changes definitive.
### Considering the following situation:
BEFORE
AFTER
```json
{
"presets": [
["@babel/preset-env", {
"spec": true,
"modules": false,
"targets": "...",
"ignoreBrowserslistConfig": true
}]
],
"plugins": [
["@babel/transform-runtime", {
"version": "^7.17.9",
"corejs": { "version": 3, "proposals": true },
"useESModules": true
}]
]
}
```
```json
{
"targets": "...",
"browserslistConfigFile": false,
"presets": [
["@babel/preset-env", {
"spec": true,
"modules": false,
"ignoreBrowserslistConfig": true
}]
],
"plugins": [
["@babel/transform-runtime", {
"version": "^7.17.9",
}],
["polyfill-corejs3", {
"method": "usage-pure"
}]
]
}
```
(Having `@babel/runtime` as a runtime dependency and `@babel/preset-env`, `@babel/plugin-transform-runtime` and `babel-plugin-polyfill-corejs3` as development dependencies, after migration.)
### The following doubts arise:
1. Will `@babel/runtime` helpers be transpiled/polyfilled? Since we are not referencing them from the corejs source anymore (`@babel/runtime-corejs3`). For example, if `@babel/runtime/helpers/asyncToGenerator` is used, will `Promise` be polyfilled inside it? (Without polluting the global scope). (Maybe this could be a problem because I think it is not possible anymore to disable general polyfills in `@babel/plugin-transform-runtime` while still importing helpers from `@babel/runtime-corejs3`.)
2. With `babel-plugin-polyfill-corejs3`, is it possible to use a specific version of `core-js`? (like `3.18.1`). **Should/can we add `core-js-pure` (or other flavor) as a runtime dependency explicitly in our library?**
3. Can proposals be 'opt-in', like with `proposals` option in `@babel/plugin-transform-runtime`?
4. Will ES6 modules always be used? How does the plugin decide when to use ES6 or CJS?
5. Is this new system beta? Can it be reliably used in critical projects? With proper testing, etc.
Hope I am not missing or confusing anything. I would really appreciate any insights.
Thank you again!
Contributor guide
Research direction
Start by reading the migration notes and the source or documentation for @babel/plugin-transform-runtime and babel-plugin-polyfill-corejs3. Clarify the five questions about helper polyfilling, core-js versions and dependencies, proposals, module format, and project stability, then document answers for the shown before-and-after configuration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100