The targets are now printed multiple times: once by preset-env (for the transform) and one by the polyfill plugin. I could inject a secret parameter used only by preset-env to avoid printing them in the polyfill provider, but I don't think that it's worth the complexity.

FWIW, I do think it's worth the complexity :)

I'm not sure why the old code included these polyfills, but the new one seems correct to me.

@merceyz If I don't update this to 0.0.11, I get this error:

➤ YN0001: │ Error: Assertion failed: /home/nicolo/Documenti/dev/babel/babel/packages/babel-plugin-proposal-async-generator-functions/node_modules/@babel/types cannot merge nodes with different link types

Is it a Yarn bug?

@nicolo-ribaudo Yes, looks like a Yarn bug, I will take a look and report back

Thanks for the ping, I forwarded it to @larixer as he has a better grip on this part of the codebase

Apparently I didn't send this comment earlier

@nicolo-ribaudo Is this line really needed:
https://github.com/nicolo-ribaudo/babel/blob/polyfill-providers/package.json#L82
I'm afraid with this line you have atypical dependency graph, when there are workspace nodes not only at the beginning of the graph, but deep inside graph and that might make the graph unrepresentable in node_modules layout. I'm still investigating and I'm not fully understand what is happening yet, but the graph you have seems very difficult with this line.

I think it's needed because:

• @babel/parser doesn't have a dependency on @babel/types, which is used for TS typings (before adding it we need to add/fix different TS types across the monorepo)
• To avoid failures, yarn uses packageExtensions to add a @babel/types dependency
• It pulls in @babel/types from npm, causing problems due to nominal types

If the problem is that line, we will fix it at some point and for now we'll make sure to have the same babel-plugin-polyfill-corejs3 in all the packages to help yarn deduping (it's working with this exact setup).

@nicolo-ribaudo Thanks, for now I think its a Yarn bug which should be fixed, I'll let you know when I have more information.

@nicolo-ribaudo Looks like the bug happens due to hoisting result is not terminal, if another pass of hoisting is done for this repo the conflict on @babel/types version is gone. I have implemented multi-pass hoisting which finishes when the result is the same on two consecutive hoisting passes here:
yarnpkg/berry#2394
For this repo 3 passes are needed, on the 1st and 2nd pass the hoisting layout changes and on 3rd pass nothing is changed, but it is still needed for algorithm to understand that we have a terminal result.
The downside of this approach is that it is obviously slower, in master hoisting takes 380ms for me, and multi-pass hoisting takes 1.28s. I'm still looking into ways to optimise multi-pass hoisting speed.