I still don't get the differences between @babel/preset-env.useBuiltIns: entry and useBuiltIns: usage

[nyngwang]

Under the section of useBuiltIns: entry:

Importing "core-js" loads polyfills for every possible ECMAScript feature: what if you know that you only need some of them? When using core-js@3, @babel/preset-env is able to optimize every single core-js entrypoint and their combinations. For example, you might want to only polyfill array methods and new Math proposals: [...]

So this sounds like it is doing the same thing as useBuiltIns: usage. But with the latter option, the result bundle size is (much) smaller. To be more specific, I added the (only) following line at the entrypoint:

import 'core-js'

and for testing, I only used 1 single feature that needs to be polyfills. But with useBuiltIns: entry, I got this debug message from my terminal:

The corejs3 polyfill entry has been replaced with the following polyfills:
  es.symbol { "android":"99", "chrome":"97", "edge":"98", "firefox":"97", "ie":"11", "ios":"12.2", "opera":"82", "safari":"14.1", "samsung":"15" }
  es.symbol.description { "android":"99", "chrome":"97", "edge":"98", "firefox":"97", "ie":"11", "ios":"12.2", "opera":"82", "safari":"14.1", "samsung":"15" }
  es.symbol.async-iterator { "android":"99", "chrome":"97", "edge":"98", "firefox":"97", "ie":"11", "ios":"12.2", "opera":"82", "safari":"14.1", "samsung":"15" }

  // many lines omitted

  web.queue-microtask { "android":"99", "chrome":"97", "edge":"98", "firefox":"97", "ie":"11", "ios":"12.2", "opera":"82", "safari":"14.1", "samsung":"15" }
  web.structured-clone { "android":"99", "chrome":"97", "edge":"98", "firefox":"97", "ie":"11", "ios":"12.2", "opera":"82", "safari":"14.1", "samsung":"15" }
  web.url { "android":"99", "chrome":"97", "edge":"98", "firefox":"97", "ie":"11", "ios":"12.2", "opera":"82", "safari":"14.1", "samsung":"15" }
  web.url.to-json { "android":"99", "chrome":"97", "edge":"98", "firefox":"97", "ie":"11", "ios":"12.2", "opera":"82", "safari":"14.1", "samsung":"15" }
  web.url-search-params { "android":"99", "chrome":"97", "edge":"98", "firefox":"97", "ie":"11", "ios":"12.2", "opera":"82", "safari":"14.1", "samsung":"15" }

But I'm pretty sure that I didn't use things like es.typed_array in my code. Is this something you called optimize in the quote?

[...] When using core-js@3, @babel/preset-env is able to optimize every single core-js entrypoint and their combinations. [...]

Any explain?

[nicolo-ribaudo]

There are two different "filters":

1. Which features are supported by your target browsers
2. Which features you are using

entry only considers (1) (thus it optimizes import "core-js" to the minimum amount of imports needed for your targets), while usage also considers (2).

[nicolo-ribaudo]

usage works in almost every case, I personally have never used entry 🤷

I would gladly accept a PR to update the docs, mentioning that useBuiltIns: usage does not inject polyfills needed by your dependencies unless you are compiling them with Babel, and that https://github.com/babel/babel-polyfills/ might be a better option if your dependencies only need polyfills but no syntax transpilation because it lets you inject polyfills without transforming everything with @babel/preset-env.

[nyngwang]

usage works in almost every case, I personally have never used entry 🤷
[...]

@nicolo-ribaudo: (Updated) Great. This solves my problem :)

I would gladly accept a PR to [...]

My pleasure. I will schedule a time for this.

[...] and that https://github.com/babel/babel-polyfills/ might be a better option if [...]

If you're interested (probably not?) you will find that I have starred and forked it hours ago because I have planned to do exactly what you're saying.

And many thanks to you: Compared with those maintainers from Webpack, you're like 100x more responsive to answer people's (dumb?) questions with details.

[nicolo-ribaudo]

My pleasure. I will schedule a time for this.

Thanks!

And many thanks to you: Compared with those maintainers from Webpack, you're like 100x more responsive to answer people's (dumb?) questions with details.

Babel and Webpack are both big projects, and unfortunately it happens that in some periods either us or them don't have time to answer to everyone! What motivates me the most is that I'm not helping "just you", but potentially anyone who will find this public discussion in the future.

[icy0307]

Excuse me , I still get little bit confused about how library author should handle their polyfill and helper. Even with the new babel/babel-polyfills .
@nyngwang @nicolo-ribaudo

Question 1: What is the best practice for library maintainers to handle browser target?

An library author still not be able to know the browser target of its potential users.
As you mentioned in RFC: Rethink polyfilling story .
Its 2022 now, very few people need to load an Array.prototype.forEach polyfill.
But as a library author, he or she has no choice.

Question 2: How should we polyfilling web API?

I know it is out of the scope of babel, But since core-js would not handle web API like requestIdlecallback.
What is the recommend way in the babel tool chains?

[nyngwang]

@icy0307 What confused you has nothing to do with how the two options were explained. Answering any of those will result in an off-topic thread. That is not appropriate.