-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deprecates babel/polyfill in favor of core-js@3 #2031
deprecates babel/polyfill in favor of core-js@3 #2031
Conversation
@@ -6,7 +6,7 @@ const { nodeEnv } = require('../env') | |||
module.exports = { | |||
test: /\.(js|mjs)$/, | |||
include: /node_modules/, | |||
exclude: /@babel(?:\/|\\{1,2})runtime/, | |||
exclude: /@babel(?:\/|\\{1,2})runtime|core-js/, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
running babel on core-js is causing issues
#2031 (comment) : this is important, as this breaks IE11 for any person polyfilling |
Babel PR: babel/babel#7646 |
package.json
Outdated
"@babel/plugin-transform-destructuring": "^7.4.0", | ||
"@babel/plugin-transform-regenerator": "^7.4.0", | ||
"@babel/plugin-transform-runtime": "^7.4.0", | ||
"@babel/polyfill": "^7.4.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, needed what? @babel/polyfill
? yes, if we remove it, then it is going to be a breaking change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Disclaimer: I know Babel and core-js pretty well, but not webpacker)
Why would it be a breaking change? Is it exposed to your users or is it only added by webpacker?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@somebody32 The document you linked seems to indicate that it needs to be removed. Apart from that, I feel like this is defenitly a breaking change since users will need to change their pack files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nicolo-ribaudo @jakeNiemiec you're right, I for some reason thought that core-js@3 and @babel/polyfill could coexist for some time, but looks like it is not the cause. My idea initially was not to remove @babel/polyfill, so builds which indirectly dependant on it will not be broken, but looks like it is safer to remove it so there will be no strange compatibility problems. I'll change that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
We should maybe have a changelog entry written up that has an upgrade guide. |
@@ -30,6 +30,7 @@ module.exports = function(api) { | |||
{ | |||
forceAllTransforms: true, | |||
useBuiltIns: 'entry', | |||
corejs: 3, | |||
modules: false, | |||
exclude: ['transform-typeof-symbol'] | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@somebody32 This suggests that @babel/plugin-transform-runtime
(line 56) can specify to use corejs: 3
as dependency. Were you able to make that work? I'm still seeing errors like these when I make that change:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great point, looks like I need to extend that too (was not using it in our project, that is why didn't spot the problem): https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md#babelruntime
tldr: try to add @babel/runtime-corejs3
package
@@ -30,6 +30,7 @@ module.exports = function(api) { | |||
{ | |||
forceAllTransforms: true, | |||
useBuiltIns: 'entry', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gauravtiwari do you think usage
should be the new default? From here:
Until Babel 7.3, useBuiltIns: usage was unstable and not fully reliable: many polyfills were not included, and many others were added without their required dependencies. In Babel 7.4, I tried to make it understand every possible usage pattern.
it does look like it's stable now. If I understand it correctly, using usage
won't require additional import. When I use:
import "core-js";
in my entry point, I get the following message:
When setting `useBuiltIns: 'usage'`, polyfills are automatically imported when needed.
Please remove the direct import of `core-js` or use `useBuiltIns: 'entry'` instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would question that. useBuiltIns: 'usage'
is not assuming anything about user's code, just expect to change import core-js
to required imports based on supported env, so you need to opt-in in into it by adding that import into one of your packs.
If we switch that to usage
, it stops being opt-in and starts automatically adding imports to the code. And from my experience, it still has some edge-cases (because core-js detects relevant import by statically analyzing, so it could not predict what you could have in a runtime), so that creates cases when you still need to add some polyfills by hand.
To summarize: I think useBuiltIns: 'usage'
is a safer choice, in general, that is very easy to change if you know what you're doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense 👍
To be honest, I'm not sure what happened to the specs, looks like a configuration issue, and I believe master branch is failing too |
docs/es6.md
Outdated
|
||
Don't forget to import `@babel/polyfill` in your main entry point like so: | ||
Don't forget add these lines into your main entry point: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't forget add these lines into your main entry point: | |
Don't forget to add these lines into your main entry point: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, thanks!
Any more action is required for this PR? |
@PikachuEXE reviewing and merging, I believe |
Thanks everyone, will review and merge this over the weekend and make a new release. |
A recent version of babel (perhaps 7.4.5?) now produces a warning about explicitly setting the
For now, I'm using the following patch .. (isProductionEnv || isDevelopmentEnv) && [
require('@babel/preset-env').default,
{
forceAllTransforms: true,
useBuiltIns: 'entry',
+ corejs: '2', Does this PR update need to update the |
@gauravtiwari Any plan to review this PR soon? |
Made a PR where I added the upgrade instructions to the changelog, feedback appreciated: #2107 Are there any other outstanding issues with |
Taking @connorshea's suggestion from #2031 (comment) to warn users who were using `@babel/polyfill`
This change breaks any project using tailwindcss just as an FYI.
For anyone else who manages to find their way here, you have to remove the |
@BobbyMcWho Thanks for pointing this out. Did you remember to run |
Yeah, I double checked all the config files, the only thing I could get to fix it was to remove the I can try and put together a reference app when I have a bit of spare time. |
Possibly related:
@BobbyMcWho Can you:
|
So the issue happens when the assets are compiled using webpack as part of
This lets tailwindcss styles get compiled just fine. Edit: Apparently I have to completely remove corejs in the above to get it to work, forgot to save after adding |
I have created a PR to fix this here (works with corejs: 3): #2110 The answer to the problem was that things break when you transpile anything that has to do with transpiling. Picture your modules doing something like this (but poorly): |
@jakeNiemiec Perhaps, we remove the corejs option in runtime plugin. Sort of confusing that we have env preset that should take care of everything with corejs enabled but we have similar options available for other plugins. Did you find any difference, if we remove corejs option from runtime plugin? |
Fully agree, plus
Setting it to false seems to fix things for quite a few users. I made a PR that implements and documents this fix: #2116 |
Taking @connorshea's suggestion from rails/webpacker#2031 (comment) to warn users who were using `@babel/polyfill`
- Prevents `@babel/plugin-transform-runtime` from rewriting babel helpers in core-js. - Remove unneeded runtime `@babel/runtime-corejs3` cc: rails/webpacker#2031, rails/webpacker#2109
Taking @connorshea's suggestion from rails/webpacker#2031 (comment) to warn users who were using `@babel/polyfill`
- Prevents `@babel/plugin-transform-runtime` from rewriting babel helpers in core-js. - Remove unneeded runtime `@babel/runtime-corejs3` cc: rails/webpacker#2031, rails/webpacker#2109
babel/polyfill is deprecated and using core-js directly is the way now.
This pr adds the required modifications to support core-js@3.
I didn't removebabel/polyfill
from the dependencies to not make this change breaking.Update: removed
babel/polyfill
because updatingcore-js
would break old usage anyway, so updating after that PR would require changes to the user's codebase