New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use async-to-generator
even when regenerator
is enabled
#10839
Conversation
While it isn't technically needed because regenerator already handles async functions, it doesn't play well with the Promise detection logic used by @babel/preset-env's useBuiltIns and @babel/transform-runtime. The plugin exclusion logic isn't removed, because 1) it will be useful when merging @babel/preset-modules into @babel/preset-env 2) if/when regenerator will support injecting a custom promise, we can enable this optimization again
This reverts commit b31980e. The change that required this was reverted in babel/babel#10839.
@nicolo-ribaudo I just updated @babel/core to be
some example code: const onClose = async () => {
try {
await <thing that returns a promise>;
} catch (err) {
return;
}
}
}; and is called from a click handler in a different react component. my package.json for babel related things in a custom preset:
and in the app that uses this preset I have
|
reverting back to 7.7.5 allows it to work again. |
Did it work before 7.7.0? If it did, then it's caused by some other change. Could you open a new issue? 🙏 |
it did, last week we were on 7.7.5 and this week updated. i'll open a new issue and link back to this one. |
core, preset env and runtime all got bumped recently so it could be one of those as well. this pr was in the change log and seemed related. |
@nicolo-ribaudo opened new issue. #10928 |
While
async-to-generator
it isn't technically needed becauseregenerator
already handles async functions, it doesn't play well with thePromise
detection logic used by@babel/preset-env
'suseBuiltIns
and@babel/transform-runtime
.The plugin exclusion logic isn't removed, because
@babel/preset-modules
into@babel/preset-env
This PR effectively reverts the behavior introduced in #9481