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
Update to core-js@3
#7646
Update to core-js@3
#7646
Conversation
f608dbb
to
178ffb1
Compare
4e6beea
to
3dbaa20
Compare
getOwnPropertyDescriptors: "es7.object.get-own-property-descriptors", | ||
assign: "es.object.assign", | ||
create: "es.object.create", | ||
defineProperty: "es.object.define-property", |
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 wonder; will, in core-js 3, it be possible to omit including the polyfill for this if your target does not include a browser that needs it?
Right now, in core-js 2, even if you don't include it via preset-env, it'll be overwhelmingly likely that whatever feature you do include the polyfill of will indirectly require the defineProperty polyfill.
It's true that it's safer that way, but it's unfortunate that you can't get significantly smaller code size even when you're specifically being unsafe by using this instead of just loading all of 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.
No, if any polyfill requires this logic - it will be added as an internal module. And it's about almost all fundamental ES5 features.
It's related this issue. You talk about the second option from this comment. It's not hard for implementation, but it will cause too many problems.
For example, Array#fill
from the issue. It requires not just Object.defineProperty
for adding this polyfill, but, for example, Object.create
for adding Array#[@@unscopables]
where should be the name of this method. Object.create
depends on Object.defineProperties
, Object.defineProperties
depends on Object.getOwnPropertyNames
, etc.
So for working es.array.fill
in IE8 we should add all of those dependencies. It's critically hard to determinate this list for manual adding. It's not so critical for babel-preset-env
, but the list of internal dependencies could be changed in core-js
, for example, after fixing any engine bug and it could be a breaking change for babel-preset-env
.
I wanted to propose this issue to discuss before core-js@4
. And it's the main problem which can be some time solved by dropping IE8 support in core-js
.
@zloirock this is looking great, mind if I regen and push the test fixtures so we can see the effects? |
@existentialism makes sense, I wanted to add some more changes and after that work on stabilisation and tests. |
7465532
to
9fd9e11
Compare
83e4d40
to
8347eb9
Compare
d6a53a8
to
36c8160
Compare
I meet the same error like: |
@suarasaur support of getters and setters can't be polyfilled or transpiled in IE8-, so you can't use it or use transforms which use it. Webpack use it for modules, so, in this case, I recommend to use |
36c8160
to
986d8f8
Compare
986d8f8
to
265d18d
Compare
bb06bc8
to
cdfc668
Compare
… version (Lyrkan) This PR was merged into the master branch. Discussion ---------- Set useBuiltIns to false by default and allow to set core-js version While working on #544 I noticed that the latest version of `@babel/preset-env` displayed a warning (which luckily made [one of the tests](https://travis-ci.org/symfony/webpack-encore/jobs/509655320) fail): ``` WARNING: We noticed you're using the `useBuiltIns` option without declaring a core-js version. Currently, we assume version 2.x when no version is passed. Since this default version will likely change in future versions of Babel, we recommend explicitly setting the core-js version you are using via the `corejs` option. You should also be sure that the version you pass to the `corejs` option matches the version specified in your `package.json`'s `dependencies` section. If it doesn't, you need to run one of the following commands: npm install --save core-js@2 npm install --save core-js@3 yarn add core-js@2 yarn add core-js@3 ``` This is related to the `core-js` 3 update that happened recently (see babel/babel#7646). As explained in parcel-bundler/parcel#2819 (comment) the issue is that users are normally supposed to add `core-js` in their root `package.json` when setting `useBuiltIns` (which is currently already set by Encore to `entry` by default). This is a problem for us since it means that: * we are requiring users to add `core-js` to their project by default (or manually setting `useBuiltIns` to `false`) * if they do they'll still have a warning because the new `corejs` option of `@babel/preset-env` won't be set (we can't do that because we won't know which version they choose to install). For now I suggest that we set `useBuiltIns` to `false` by default and add a new option to `Encore.configureBabel()` that allows to set the `corejs` option. Commits ------- 85896ef Set useBuiltIns to false by default and allow to set corejs version
Seeing a lot of: _Object$defineProperty is not a function Scanning the release notes: https://github.com/babel/babel/releases This one stands out: https://github.com/babel/babel/releases/tag/v7.4.0 Specifically, "Update to core-js@3": babel/babel#7646 There are 133 comments which I confess to not having read, and various offshoots to places like: babel/babel#9442 and: facebook/regenerator#369 I did find this enormous update doc, but haven't found the answer in there yet and the Babel docs themselves don't appear to have been updated: https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md Although this blog post is briefer and covers a few things: https://babeljs.io/blog/2019/03/19/7.4.0 In the end the build works if I get rid of `@babel/plugin-transform-runtime`, which doesn't seem to play too well in conjunction with `@babel/preset-env`, at least in this set-up.
Current state:
@babel/runtime
@babel/runtime-corejs3
package andcorejs: 3
options to@babel/plugin-transform-runtime
.proposals
(incorejs: { version: 3, proposals: true }
format) for support all proposals polyfills fromcore-js
.core-js
entry points with proposals and without.get-iterator-method
helper for getting iterators, fixes When using babel-runtime, Symbol.iterator is different in user code & in polyfills #2500.regenerator
).@babel/polyfill
core-js
andregenerator-runtime
with an informative message.@babel/preset-env
core-js-compat
instead ofcompat-table
since information fromcompat-table
is not enough.useBuilIns
now requires direct setting ofcorejs
version option, without it will be used2
by default and shown deprecation warning.core-js
versions for simplify updating in the future.core-js@3
plugins added onpost
stage in the order ofcore-js-compat
data.preset-env
, instead of 2 internal plugins for adding polyfills, we have 6: usage and entry versions of plugins forcore-js@2
,core-js@3
,regenerator-runtime
.samsung
target (for Samsung Internet) sincecore-js-compat
andcompat-table
now contains mapping for this, fixes Add support for Samsung Internet browser #6602.useBuilIns: entry
withcorejs: 3
@babel/polyfill
.core-js
entry points to import of related modules (based on data fromcore-js-compat
).shippedProposals
/proposals
flags withuseBuilIns: entry
.regenerator-runtime/runtime
import where it's not required.useBuilIns: usage
withcorejs: 3
shippedProposals
, added flagproposals
(incorejs: { version: 3, proposals: true }
format) for polyfill all proposals fromcore-js
.MemberExpression
,ObjectPattern
,in
operator.for-of
, destructuring, spread,yield
delegation, etc.).core-js@2
stuffI didn't want to tough
core-js@2
-related stuff, howeverObject.getOwnPropertySymbols
,Symbol.toStringTag
logic,Promise#finally
,Array#forEach
, etc.Array#flatMap
and trim methods moved to stable features as a part of ES2019 and loaded by deprecated@babel/polyfill
and@babel/preset-env
withcorejs: 2
option.2018.12.30 Explanation of the current situation:
@babel/runtime
Here we have no serious problems.
@babel/runtime-corejs3
package andcorejs: 3
options to@babel/plugin-transform-runtime
.get-iterator-method
helper for getting iterators, fixes When using babel-runtime, Symbol.iterator is different in user code & in polyfills #2500.regenerator
).Breaking changes
@babel/runtime
can be updated without any problems by adding@babel/runtime-corejs3
package. But not@babel/polyfill
and@babel/preset-env
.Updating
@babel/polyfill
tocore-js@3
will break@babel/preset-env
.@babel/preset-env
withuseBuiltIns
transforms import of@babel/polyfill
to import of requiredcore-js
modules. Most users don't addcore-js
dependency directly. In case of a minor update, even if@babel/polyfill
dependency will be updated with@babel/preset-env
, in the top level ofnode_modules
we will havecore-js@2
, notcore-js@3
because a serious part of dependencies depends on packages withcore-js@2
in dependencies.Updating
@babel/preset-env
will cause the same problem. More other,@babel/preset-env
transforms also imports ofcore-js
. If someone hascore-js@2
in dependencies, a minor update of@babel/preset-env
will break it.Before
babel@7
release, I proposed to deprecate@babel/polyfill
in favor of separate inclusion ofcore-js
andregenerator-runtime
, but it was not done.So,
Options for
@babel/polyfill
:@babel/polyfill
.@babel/polyfill
package in favor recommendation of separate inclusion of required parts ofcore-js
andbabel-runtime
.Options for
@babel/preset-env
:@babel/preset-env
.core-js
like in@babel/plugin-transform-runtime
. I'm not a fan of this way, because in this case, we will use a deprecated version ofcore-js
by default, will cause spaghetti in configs and the code base and will cause problems for other mentioned here changes, at least, seepolyfilling of proposals
section.useBuiltIns
option of@babel/preset-env
in favor of creation plugin(s) / preset in the scope ofcore-js
for polyfills only.@babel/preset-env
Some of the improvements already added, some should be added.
compat-table
is not enough for correct detection of environments wherecore-js
modules required. More info about it you could find here. So I madecore-js-compat
package with required data which should be used here.babel@7
release, some still not.Promise
with dependencies (@babel/preset-env not always polyfilling Promise #9250), etc.Polyfilling of proposals
In the final
babel@7
versions, from all polyfilling-related stuff was removed polyfilling of proposals. Seems that it was a mistake.New babel plugins for proposals will rely on new standard library features. And, with the current approach to polyfilling of proposals, it's too problematic.
I can understand why polyfilling of proposals was removed from the default
@babel/polyfill
. But in this case, we should have added entry points which include proposals.Adding polyfills of proposals from
core-js
when the main part of polyfills loaded from@babel/polyfill
is not a good solution because they could be loaded from another instance ofcore-js
and it will cause problems.Removing proposals from
runtime
will kill usage of new proposal plugins which depends on new standard library features with theruntime
. They should be available in helpers. Even import of required part ofcore-js
without global namespace pollution is rocket science for a serious part of developers. Also,@babel/runtime-corejsx
is not@babel/runtime-stable-corejsx-features
.The same for
@babel/preset-env
, but not so critical.@babel/preset-env
transformscore-js
only to import of stable ES features. But the maincore-js
entry point also contains proposals and someone can expect some of them.runtime
andpreset-env
inject polyfills based on feature detection, only when they are used, so I don't see any arguments why polyfilling of proposals was removed from those tools.The
shippedProposals
option of@babel/preset-env
looks like something strange. We haven't any equal incore-js
entry points, so I don't see what should be transformed. Implementing in browser definitely is not an indicator that it should be polyfilled, but non-implemented proposals should not. I don't think that it's something that should be supported.So, by my vision, the best approach is:
@babel/polyfill
in favor recommendation of separate inclusion of required parts ofcore-js
andbabel-runtime
. If someone needs polyfills of proposals - he will use polyfills of proposals, not - not.@babel/polyfill
in@babel/preset-env
.preset-env
withuseBuiltIns: entry
(or a successor for polyfilling) transforms:core-js
to all modules,core-js/es
,core-js/proposals
andcore-js/web
to related parts ofcore-js
.runtime
andpreset-env
inject proposals polyfills. Maybe - with an option for that, but option will make it harder.--------------------
Before the next step, we should decide what should we do with
@babel/polyfill
,@babel/preset-env
breaking changes and polyfilling of proposals. Thoughts?