Should we combine the transform-runtime and preset-env in an application?

[NE-SmallTown]

Question 1

I find that there are many unnecessary duplications in the (webpack) bundle (output)result, to be specific, they all are the helpers(like classCheck, objectSpread(due to the object-spread plugin).

So, I want to reduce the duplications. If it's a library, sure, I will use transform-runtime plugin(refer to runtime-corejs3) to do this. But now this is an application, so, what's the correct way to do this?

Therefor I'm getting confused because the transfrom-runtime plugin is recommended for library(and is for the whole reduction. i.e. core-js, regenerator and the helpers). But here I just want to reduce the helper duplications, not others duplications because that has been done by preset/env.

So here the question I want to ask/discuss is that is it necessary to reduce the helpers duplications in an application, if yes, and how?

Question 2

The other question is, core-js/modules/es.promise.js and core-js-pure/modules/es.promise.js are exactly the same code, the main difference just is that the former has global pollution? If so, why core-js doesn't use(directly import) core-js-pure to polyfill and then add it to global? IMO, this will greatly reduce the duplications because at now the libs use transform-runtime(finally core-js-pure) but apps use preset-env(finally core-js), there is no shared/shareable codes between apps and libs, right?

[babel-bot]

Hey @NE-SmallTown! 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."

[nicolo-ribaudo]

The docs are confusing: @babel/transform-runtime's corejs option is recommended for applications, but it's not discouraged for libraries. We only want to discourage using any polyfill injecting method that is not @babel/transform-runtime's corejs option when creating libraries.

Also, we are currently reworking our methods to inject polyfill to unify them: #10008

If so, why core-js doesn't use(directly import) core-js-pure to polyfill and then add it to global?

This should be asked in the core-js repository 🤷

[JMarkoski]

Answer to the first question: To reduce the helper duplication you should use the @babel/transform-runtime plugin together with the @babel/runtime dependency. The corejs option of the @babel/transform-runtime plugin should be set to false. This way the plugin will alias the helpers to the @babel/runtime dependency, and every helper will be included only once in the application, thus reducing the size. For more thorough answer, see here: #9853 (comment)

[NE-SmallTown]

Thanks, it's more clear now!

The second question has beeen refered to zloirock/core-js#833