-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
@babel/preset-env: Clarify useBuiltIns
usage and purpose
#2067
Conversation
Deploy preview for babel failed. Built with commit 6f82595 https://app.netlify.com/sites/babel/deploys/5e6c15e822b418000b7f7649 |
Could we also add a note that it is incompatible with |
|
||
Since `@babel/polyfill` was deprecated in 7.4.0, we recommend directly adding `core-js` and setting the version via the [`corejs`](#corejs) option. |
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.
This note is useful for many users, so I don't think that remove it and add a stripped version is a good idea.
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 have a line below that reads:
> NOTE: Previously, these would be installed via `@babel/polyfill`, which is now deprecated. The above method of installing these polyfill packages is the recommended way.
I don't see this as any more stripped down than the line you commented on, just moved down to be more contextual. Do you want me to move this line up?
|
||
npm install core-js@2 --save |
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.
Usage of different core-js
versions causes many questions and problems for users, so remove the note of how to install different core-js
versions is not a good idea.
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.
That's what I was trying to do by removing the different versions. I found the fact that the documentation had two different versions of core-js
confusing -- why are there two? Which one should I be using? It made me do unnecessary research into core-js
, which I don't think a user of @babel/preset-env
should have to do.
Are there specific use cases for 2 vs 3? If so, I'd be happy to add notes about them 馃檪
@nicolo-ribaudo But if preset-env and transform-runtime don't work together, won't people lose the benefit of sharing the runtime/helper code across the entire project? Not sure people are going to like that. |
Sorry, I meant with |
Do you have wording in mind on this? Might be easier than me trying to come up with something and having it be inaccurate 馃槄 |
docs/preset-env.md
Outdated
|
||
Since `@babel/polyfill` was deprecated in 7.4.0, we recommend directly adding `core-js` and setting the version via the [`corejs`](#corejs) option. | ||
- `core-js`: For standard JS built-ins | ||
- `regenerator-runtime`: For generator and `async`/`await` support |
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.
Note that this isn't needed for async
/await
if your browser supports generators. (because async
/await
is transpiled to a generator)
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.
Can you also mention this here?
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.
Isn't that assumed for this whole section, since preset-env
's entire purpose is to fill in for browsers' shortcomings.
i.e. core-js
isn't needed if your browser supports all JS built-ins that it brings
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.
My point was that regenerator-runtime
isn't always needed by browsers that don't support async
/await
, while this sentence implies the opposite.
regenerator-runtime
is only needed for browsers that don't support generators.
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 see what you mean, but don't know exactly what text would make sense.
Do you have a suggestion?
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.
Maybe this?
- `regenerator-runtime`: For generator and `async`/`await` support | |
- `regenerator-runtime`: For generators and `async`/`await` in browsers without generators support |
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. Changed up your suggestion a little. I don't think everyone knows that async
/await
is built on generators, so I just grouped them together so it would be clear for everyone
Co-Authored-By: Nicol貌 Ribaudo <nicolo.ribaudo@gmail.com>
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.
Let's get this landed, I just made a few small comments.
> Multiple imports or requires of those packages might cause global collisions and other issues that are hard to trace. | ||
> We recommend creating a single entry file that only contains the `import` statements. | ||
|
||
This option enables a new plugin that replaces the `import "core-js/stable";` and `import "regenerator-runtime/runtime"` statements (or `require("corejs")` and `require("regenerator-runtime/runtime")`) with individual requires to different `core-js` entry points based on environment. | ||
This option enables a new plugin that replaces the `import "core-js"` and `import "regenerator-runtime/runtime"` statements with only what's needed from each of them, depending on the target environments. |
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.
This option enables a new plugin that replaces the `import "core-js"` and `import "regenerator-runtime/runtime"` statements with only what's needed from each of them, depending on the target environments. | |
This option enables a plugin that replaces the `import "core-js"` and `import "regenerator-runtime/runtime"` statements with only what your target environments need from each of them. |
npm install core-js@3 --save | ||
|
||
# or | ||
Since these packages do not come with Babel or `@babel/preset-env` itself, they'll need to be installed as production-level dependencies. This way, when the Babel-generated code imports them, they'll be accessible (in `node_modules`). |
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.
Wonder if we should be more explicit than "production-level", something like:
installed a
dependencies
(notdevDependencies
)
Co-Authored-By: Nicol貌 Ribaudo <nicolo.ribaudo@gmail.com>
This PR clarifies what
useBuiltIns
is for, and how to use it, better (IMO 馃檪).Specifically, I really struggled using this option in one of my projects. It took me a long time to understand:
npm install
them yourselfcore-js
andregenerator
/regenerator-runtime
were exactly the two polyfills it supportedcore-js
, and brushes overregenerator
regenerator-runtime/runtime
was installed via theregenerator
npm packageregenerator-runtime
? Justregenerator
?)Feedback welcome 馃槂