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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out plan for polyfilling library functionality stage < 4 #8416

loganfsmyth opened this issue Aug 3, 2018 · 1 comment

Figure out plan for polyfilling library functionality stage < 4 #8416

loganfsmyth opened this issue Aug 3, 2018 · 1 comment


Copy link

@loganfsmyth loganfsmyth commented Aug 3, 2018

Now that we've removed the stage presets, there's still the question of how we want to handle stage < 4 proposals for library functionality, rather than syntax.

In Babel 6 (and 7 for now), we just load core-js@2, which meant we auto-loaded anything that core-js decided to polyfill, including anything that is still experimental.

Given the precedent for 7.x with the presets, it seems like we should consider having the default @babel/polyfill only polyfill things that are stage 4/standard. We can still for instance expose specific features, once they land in core-js, as like

import "@babel/polyfill/some-experimental-feature";

which would likely be enough?

As with syntax, this would also things safer for us as proposals evolve over time, because we can leave the existing polyfill files, but add additional ones alongside when things change.

@loganfsmyth loganfsmyth added this to the Babel 7 RC milestone Aug 3, 2018
Copy link

@hzoo hzoo commented Aug 3, 2018

Yeah I think we can emulate what we are doing with proposals in transforms?

So in v7 "import "@babel/polyfill" is only what is Stage 4? and opt into specific ones.

later: I guess the other question (really need to think about this), is whether we really need the alias if it's just core-js (also related is switching out core-js for other polyfills for transform-runtime/preset-env)

@hzoo hzoo closed this in #8440 Aug 9, 2018
@lock lock bot added the outdated label Nov 8, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Nov 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants
You can’t perform that action at this time.