Hey @julien-f! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

For what its worth - I will work soon-ish on implementing support for custom polyfills in preset-env (core-js tends to be huge). Will also look into providing the same thing (custom polyfills) but used as modules and not polluting the global scope. Fine-grained control will have to be added, as we cannot really assume what a custom polyfill looks like (if it polyfills globally automatically or not)

Somewhat related: #6830

@Andarist Fine-grain control over polyfilling would be amazing. Any thoughts on what the configuration would look like?

Duplicates #6629 and relates also to #6628.

This is feature is desperately needed, and is a low hanging fruit. It is the final missing piece of the preset-env puzzle.

@hzoo I really wish Babel would prioritise features for package authors rather than package consumers, because the positive effects ripple throughout the community on a massive scale. People who use packages to complete commercial projects are paid to solve their problems one way or another, but even a little bit of friction caused by tools really distracts and demotivates people working for free to produce open source packages that benefit everyone.

It's sad this issue hasn't been triarged with tags or anything since it was raised over 2 months ago in January.

Many packages have ~ 1kb source yet ~20kb of polyfills added by babel because authors are stuck between choosing:

• preset-env with `useBuiltIns: 'usage', where polyfills imported as a side-effect:
  • ✔️ Only polyfills for your targeted environments.
  • ❌ Effects the global scope.
  • ❌ Can't be treeshaken/eliminated.
  • ❌ Prevents being able to declare "sideEffects": false for Webpack optimisations.
• transform-runtime with polyfill: true, where polyfills are imported as helpers:
  • ❌ Instead of only polyfilling for your targeted environments, every possible thing is pollyfilled adding many unnecessary kb.
  • ✔️ Doesn't affect global scope.
  • ✔️ Can be treeshaken/eliminated.
  • ✔️ Can declare "sideEffects": false.

@jaydenseric

I definitely agree that it would be great to have this too. Regarding transform-runtime specifically, it doesn't work with any instance methods. So anything like Array.prototype.x won't be handled by runtime correctly.

Yes, I made those issues because I had wanted to tackle them but I had personal stuff to deal with (and still dealing with) and there are other priorities as well like releasing v7 among other things.

This is feature is desperately needed, and is a low hanging fruit. It is the final missing piece of the preset-env puzzle.
but even a little bit of friction caused by tools really distracts and demotivates people working for free to produce open source packages that benefit everyone.
It's sad this issue hasn't been triarged with tags or anything since it was raised over 2 months ago in January.
authors are stuck between choosing:

I'm confused by this. I don't think it's that productive to just point out that the work isn't done and is easy. I feel like there's an issue with your statement - isn't what you are saying the same thing that would equally demotivate someone to work on this issue as well?

Are you saying that because we aren't focusing on this issue that is demotivates you and others from doing open source? If this is something you really want to happen you can also help with this effort as well. I don't think it's easy, but if it is then we are open to you or someone else making a pull request too, or getting help/feedback on it in Slack as well. I'd like to think we don't just use GitHub as a place to ask for feature requests only the maintainers will do, but that people will get involved and actually do the work they want to see happen. There are actually other things that are important, and not a lot of people working on this project (although it does feel like people forget that). Even if everyone was full time it wouldn't be enough, let alone now.

Libraries bringing in their own polyfills, even if self-contained library-like ones, is actually a problem for final users / packagers because, if they do polyfill their environment, they now have the library redundantly trying to use their library-isolated polyfill while the global environment is already polyfilled.

I don't think there's any "right answer" here; I lean on the side of having final users provide all polyfills, and libraries should document which ones they need.

Once we get preset-env safe for use in (most of) node_modules, I believe we'll be closer to that ideal.

@hzoo

Regarding transform-runtime specifically, it doesn't work with any instance methods.

I'm aware, and don't use instance methods. It is be a good addition to the pros/cons list though.

Are you saying that because we aren't focusing on this issue that is demotivates you and others from doing open source?

Yes. It is fair to say learning best practices and what is or isn’t possible regarding transpilation and polyfilling cost several weeks over 2 years, making frustrating or embarrassing mistakes along the way. At the moment, I don't feel confident promoting my latest package until the polyfill situation is under control.

I don't think it's that productive to just point out that the work isn't done and is easy.

Triaging issues for maximum impact is productive. I don't mean that working on the feature is easy per se, but that it is comparatively easy compared to the volume and complexity of other things being worked on.

I feel like there's an issue with your statement - isn't what you are saying the same thing that would equally demotivate someone to work on this issue as well?

My intention is not to demotivate anyone, but rather to motivate package authors to support each other as a priority. The barriers to entry to writing best practice packages are prohibitively high. We should not have to choose certain best practices sacrificing others.

I'd like to think we don't just use GitHub as a place to ask for feature requests only the maintainers will do, but that people will get involved and actually do the work they want to see happen.

I feel you and appreciate your efforts ❤️. I only share this so you don’t think of me as a parasite… But I quit my job a year and a half ago to immerse in open-source and have spent many months working unpaid, full time (spending tens of thousands of dollars of personal savings) on projects such as the GraphQL multipart request spec, apollo-upload-client/apollo-upload-server and recently graphql-react. I contribute PRs to several projects; I just have nothing left to give to solve this particular issue. If I could clone myself and learn enough about the inner workings of Babel to do it I would!

@rtsao I'm wondering where we're at with this issue, or if anyone could give me some guidance on setting up a babel configuration to solve a very unique problem. I've asked stack-overflow and the slack community already.

TLDR: I'm building a library as a node_module. Shared node_module dependencies between my library (imported as a node_module) and my main "parent" application that requires it - can collide and cause issues. How can i create a babel config in the library to avoid polluting the global namespace?

Longer description:
Context: I'm building a library (as a node_module), to be imported by decentralized applications that are built on the ethereum blockchain. In this development environment, a common pattern is that an ethereum "wallet" (in my case, a google chrome extension) injects a web3 object into the browser through the window object. In my case, this web3 object is of version 0.20.3.

Problem: When I import my node_module (that imports web3 as its own dependency), suddenly the version of web3 in the main application jumps to the version imported in the node_module. Does @babel/preset-env compile imports (in the non-compiled codebase) as global imports in the compiled version (like @babel/polyfill) instead of "sandboxing" the library, isolated from the application that requires it? If so, how can I avoid this issue?

The stack overflow post with more specific code examples is here: https://stackoverflow.com/questions/52507114/how-do-i-compile-code-for-a-web3-js-related-sdk-so-it-doesnt-interfere-with-the

I've experimented with many babel presets, and I'm not sure if there is one plugin that is causing this issue, or if it's even possible to create a dependency graph in a node_module without touching the global namespace.

@julien-f I saw you said that the @babel/plugin-transform-runtime approach is nice, but not really sure what you meant. I tried a babel config like:

const presets = []
const plugins = [["@babel/plugin-transform-runtime" , {
  "corejs": false,
  "helpers": true,
  "regenerator": true,
  "useESModules": false
}]]

module.exports = { presets, plugins };

Yet I still get the same issue. Do I have to do something with corejs?

any progress?

@babel/preset-env now has useBuiltins: 'usage', and while it's not yet perfect, I think the original issue has been mostly resolved.

I agree, let's close this for now 🙂