Skip to content
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

Closed
wants to merge 6 commits into from

Conversation

bowernite
Copy link

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:

  • That this option only told Babel how to import polyfills, and that it didn't come with them
    • Specifically, that you had to npm install them yourself
  • core-js and regenerator/regenerator-runtime were exactly the two polyfills it supported
    • The old documentation focuses on core-js, and brushes over regenerator
  • regenerator-runtime/runtime was installed via the regenerator npm package
    • Just took me a while to figure which exact package to install (regenerator-runtime? Just regenerator?)

Feedback welcome 馃槂

@netlify
Copy link

netlify bot commented Jul 19, 2019

Deploy preview for babel failed.

Built with commit 6f82595

https://app.netlify.com/sites/babel/deploys/5e6c15e822b418000b7f7649

@nicolo-ribaudo
Copy link
Member

Could we also add a note that it is incompatible with transform-runtime? (ref: babel/babel#10271)

docs/preset-env.md Outdated Show resolved Hide resolved

Since `@babel/polyfill` was deprecated in 7.4.0, we recommend directly adding `core-js` and setting the version via the [`corejs`](#corejs) option.
Copy link
Member

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.

Copy link
Author

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
Copy link
Member

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.

Copy link
Author

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 馃檪

@patrick-mcdougle
Copy link

Could we also add a note that it is incompatible with transform-runtime? (ref: babel/babel#10271)

@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.

@nicolo-ribaudo
Copy link
Member

Sorry, I meant with transform-runtime's core-js option

@bowernite
Copy link
Author

Could we also add a note that it is incompatible with transform-runtime? (ref: babel/babel#10271)

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 Show resolved Hide resolved

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
Copy link
Member

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)

Copy link
Member

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?

Copy link
Author

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

Copy link
Member

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.

Copy link
Author

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this?

Suggested change
- `regenerator-runtime`: For generator and `async`/`await` support
- `regenerator-runtime`: For generators and `async`/`await` in browsers without generators support

Copy link
Author

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

docs/preset-env.md Outdated Show resolved Hide resolved
bowernite and others added 2 commits November 4, 2019 19:32
Co-Authored-By: Nicol貌 Ribaudo <nicolo.ribaudo@gmail.com>
Copy link
Member

@existentialism existentialism left a 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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`).
Copy link
Member

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 (not devDependencies)

docs/preset-env.md Outdated Show resolved Hide resolved
Co-Authored-By: Nicol貌 Ribaudo <nicolo.ribaudo@gmail.com>
@bowernite bowernite closed this Nov 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants