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

Clarification about coreAliasing #446

Closed
fkling opened this issue Jan 10, 2015 · 3 comments
Closed

Clarification about coreAliasing #446

fkling opened this issue Jan 10, 2015 · 3 comments
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue

Comments

@fkling
Copy link
Contributor

fkling commented Jan 10, 2015

Will coreAliasing only apply to the shims used by 6to5 itself or to all core-js shims (in the developers code (I know it works for Array.from at least))?

The website says:

This means that you can use every single 6to5 feature without a globally polluting polyfill, minus caveats and all.

However, this doesn't seem to apply to the regenerator runtime, so it's not possible to use every single feature without a polyfill. While the regenerator runtime is listed in the caveats section, it's not clear whether it applies to it, since Array.from is listed there as well.

This all leads to my actual question: Can we do this for all core-js shims, the regenrator runtime, and the 6to5 runtime, so that libraries are truly self contained and don't pollute the global namespace?

Right now I'm concatenating the 6to5 runtime before my actual code. Would be great if I could avoid that.

@sebmck
Copy link
Contributor

sebmck commented Jan 11, 2015

Ah yeah, the docs is definently ambiguous/wrong. All the coreAliasing transformer does is transform arr[Symbol.iterator]() and ES6 methods such as Array.from to their core-js equivalent. It's definently possible to add a way to use the to5Runtime in the same way. There's currently no way to include the regeneratorRuntime without polluting the global scope, perhaps @benjamn can help here?

@sebmck
Copy link
Contributor

sebmck commented Jan 21, 2015

Not relevant anymore with the introduction of selfContained in 3.0.0

@sebmck sebmck closed this as completed Jan 21, 2015
@fkling
Copy link
Contributor Author

fkling commented Jan 21, 2015

👍

@lock lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Jan 18, 2019
@lock lock bot unassigned sebmck Jan 18, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jan 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue
Projects
None yet
Development

No branches or pull requests

2 participants