Using @babel/runtime-corejs* still uses the global Promise for generators/async-fns

[loganfsmyth]

I thought this was something we'd addressed at some point, but I guess not?

regenerator-runtime uses the global Promise, even if we're trying to use it via one of the standalone runtime modules like @babel/runtime-corejs3. In an ideal world, we'd be able to pass in the Promise implementation that the regenerator runtime should use, or else transform the regenerator runtime at publish time and include a copy of it inside the babel runtime, or something.

[mreinstein]

I was definitely burned on this. here is a minimal repro example.

https://github.com/mreinstein/babel-async-min-example

To reproduce the problem:

1. clone this repo
2. comment out these lines: https://github.com/mreinstein/babel-async-min-example/blob/master/rollup.config.js#L14-L34 (this is a workaround for the problem that @loganfsmyth produced)
3. npm run build
4. open index.html in a browser that lacks Promise support (ie 11 for example)
5. notice the console error about Promise being undefined.

[nicolo-ribaudo]

cc @benjamn What do you think that would be best to do?

[marcelgerber]

I actually have a test case that worked fine in Babel 7.6.2, but is broken with Babel 7.7.2.
You can find this test case in https://github.com/MarcelGerber/babel-bug-regenerator-promise. There is a working branch using 7.6.2, while the master branch is not working (7.7.2).
The diff between these two branches (including the built file!) can be seen here: https://github.com/MarcelGerber/babel-bug-regenerator-promise/compare/working...master

See also: The README

Environment

• Babel version(s): 7.7.2 (broken), 7.6.2 (working)
• Node/npm version: 10.17.0
• OS: Windows 10
• How you are using Babel: Webpack babel-loader

IE11 complains about this Promise call: https://github.com/MarcelGerber/babel-bug-regenerator-promise/blob/6687cfca00423eac3fa6b2c6d95b30e57bde5015/build/index.js#L3279

[marcelgerber]

This (at least my) problem is caused by #9481. Disabling the async-to-generator step makes it such that global Promise is used in the code generated by regenerator.

[nicolo-ribaudo]

@marcelgerber / @mreinstein
Could you comment out these lines?
https://github.com/nicolo-ribaudo/babel/blob/f087c3f5bbcafd6d9689f261798ae809b9fb4fcc/packages/babel-preset-env/data/overlapping-plugins.js#L6-L7

I want to keep the logic because it will be useful in the future for something we are working on and because I'd like to avoid using async-to-generators when we already use regenerator, but let's fix the regression for now.

[marcelgerber]

@nicolo-ribaudo Yes, that's exactly what I did yesterday. With these two lines commented out everything works just fine.

[benjamn]

Is this an application-level concern, such that setting regeneratorRuntime.Promise once, in some sort of global setup code, might be a good solution, or would it make more sense to allow passing a specific Promise implementation to each regeneratorRuntime.async call (once per async function, essentially)?

[marcelgerber]

@benjamn I don't know exactly what you're asking, and I think you know the correct answer better than I do.

But if I understand your question correctly, then I think a global one-time-setup code would suffice. I don't see why someone would need multiple, different Promise implementations.

[nicolo-ribaudo]

From a transformer point of view, I think that it would be easier to pass it as a parameter.

@marcelgerber I realize that my previous comment wasn't clear at all, but I was asking if you want to open a PR commenting out that lines 😅
That way we can fix the regression in the next patch.

[marcelgerber]

Can confirm this is working now in v7.7.7 with #10839.

[nicolo-ribaudo]

I'll keep this issue open since I would like to reintroduce the commit we had to revert

[nicolo-ribaudo]

This should be fixe by facebook/regenerator#383, because now we use the polyfilled promise with regenerator.