Closed swernerx closed 6 years ago
Can you try with fast-async in your plugins first and last, and let me know if it's different?
There is just one plugin. The one used is from the PR of you to Babel. Should be pretty much identical to fast-async. Plus I use the latest nodent transform.
Hi Mat!
I have uploaded a small extracted demo case to a gist together with some results being produced: https://gist.github.com/swernerx/7ca748fcddab4c672193b614e62cc73e
Please have a look. Should be pretty much reproducible for you as well. Hopefully this helps to track the issue down.
I was having a few issues pushing changes to my Babel fork, which I eventually resolved by pulling the latest Babel source and re-merging before make clean
and retest. My changes to transform-async-to-promises
now pass all the tests (https://github.com/babel/babel/pull/7076 is green again).
Can I suggest you pull the changes again and retry? Mixing Babel beta-versions (in this case .44 and .46) is clearly not a good base from which to test.
@swernerx - thanks for the gist. It would be really good if you could just generate a repo I could clone and npm test
. There are so many versions of Babel, etc., trying to reproduce an exact error is proving difficult.
Here we go: https://github.com/swernerx/test-babel-async
Unfortunately it seems that the env-preset is always executed before fast-async.
Thanks for the repo :) The issue seems to be the Babel implementation of for await (....)
, which is probably fighting with fast-async. The exception occurs while Babel tries to create a template internally:
async function wrapper() {
var ITERATOR_COMPLETION = true;
var ITERATOR_HAD_ERROR_KEY = false;
var ITERATOR_ERROR_KEY;
try {
for (
var ITERATOR_KEY = GET_ITERATOR(OBJECT), STEP_KEY, STEP_VALUE;
(
STEP_KEY = await ITERATOR_KEY.next(),
ITERATOR_COMPLETION = STEP_KEY.done,
STEP_VALUE = await STEP_KEY.value,
!ITERATOR_COMPLETION
);
ITERATOR_COMPLETION = true) {
}
} catch (err) {
ITERATOR_HAD_ERROR_KEY = true;
ITERATOR_ERROR_KEY = err;
} finally {
try {
if (!ITERATOR_COMPLETION && ITERATOR_KEY.return != null) {
await ITERATOR_KEY.return();
}
} finally {
if (ITERATOR_HAD_ERROR_KEY) {
throw ITERATOR_ERROR_KEY;
}
}
}
}
I'll see if I can work out why. If you're not using the for await
construct, it might be easier to simply disable it for now.
What do you mean by disabling?
I am updating a generally used preset. I don't think I can communicate to all why for-of loops with await shouldn't be used. So it's not only about me.
I meant if you want to continue your development while I look into it!
Confirmed: this is a bug in nodent-transform - it produces an illegal Identifier transpiling the output of babel's for-of transform. I hope to be able to find/fix it soon. Thanks for the help in identifying and reproducing it!
@swernerx - please let me know if this fixes the issue as expected
Looks good for me! Thanks!
I have another exception I got in a pretty trivial case.
Code:
Babelrc:
Command Line:
Exception:
I modified the generator a bit to catch this case:
Generated output with fix:
The problematic code is at line 35:
Do you have any idea what's wrong?