Closed Rush closed 8 years ago
It works for me (see link below). Could it be that async liveBackup
should be async function liveBackup
?
Please confirm and close or provide additional information.
This function is part of an object. I will try to make a small reproducible test-case.
Thanks. From the stack trace, it looks like it might be related to the let
. If you can get something to work in the playground, but not in Babel, let me know as it might be an unpleasant interaction between Babel and Nodent.
@matAtWork ok, this the most minimal case that breaks:
async function liveBackup() {
for(let file of files) {
await Promise.resolve();
}
for(let file of files) {
await Promise.resolve();
}
}
npm install fast-async-issue-13
cd node_modules/fast-async-issue-13
npm test
Yep, that's a bug. Nodent is mangling the scope for declarations within a for-loop. I'll work on a fix. The only workaround I can suggest short-term is to use different variable names in your for loop declarations, or use 'var' since it has function scope.
I was merely curious about nodent. Using async to bluebird coroutine works fine. I will give it another shot once the bug is fixed though.
btw. will stacktraces show proper line numbers in nodent when combined with babel?
I doubt it. Nodent's stack trace mapping is a run-time feature, which I imagine Babel mangles as the sourcemaps generated by Nodent won't make through to execution. TBH, I've not tried - it might work depending on how transparent Babel is.
I've fixed the bug in Nodent v3 (not released yet), and almost back-ported it to v2.6.x but one of the main differences is how async loops are transpiled so it's a work in progress.
Nice, I'll try it out after the release. If you generate an inline source map then babel should pick it up.
Just published v2.6.10 which (I hope) fixes this issue. Please check on the link above.
I've not updated fast-async (yet) as I'll do that when I'm ready to ship v3. You should get the update automatically if you uninstall and re-install fast-async in your project.
Let me know how it goes, and thanks for the report
It seems to have fixed it. Also, sourcemaps seem to work but they are not enabled by default. Is it a bug?
I had to add the option to .babelrc
{
"presets": [],
"plugins": [["fast-async", {
"compiler": {
"sourcemap": true
}
}]]
}
Error
at $ForStatement_1_loop (/code/fast-async-issue-13/test.js:4:17)
at Function.boundThen [as then] (/code/fast-async-issue-13/test.js:122:21)
at /code/fast-async-issue-13/test.js:1:1
at boundThen (/code/fast-async-issue-13/test.js:122:21)
at liveBackup (/code/fast-async-issue-13/test.js:1:1)
at Object.<anonymous> (/code/fast-async-issue-13/test.js:13:1)
at Module._compile (module.js:556:32)
at loader (/code/fast-async-issue-13/node_modules/babel-register/lib/node.js:143:5)
at Object.require.extensions.(anonymous function) [as .js] (/code/fast-async-issue-13/node_modules/babel-register/lib/node.js:153:7)
at Module.load (module.js:473:32)
Error
at $ForStatement_1_loop (/code/fast-async-issue-13/test.js:4:17)
at $ForStatement_1_next (/code/fast-async-issue-13/test.js:1:1)
at /code/fast-async-issue-13/test.js:5:5
at then (/code/fast-async-issue-13/test.js:115:126)
at process._tickCallback (internal/process/next_tick.js:103:7)
at Module.runMain (module.js:592:11)
at run (bootstrap_node.js:394:7)
at startup (bootstrap_node.js:149:9)
at bootstrap_node.js:509:3
Error
at $ForStatement_1_loop (/code/fast-async-issue-13/test.js:4:17)
at $ForStatement_1_next (/code/fast-async-issue-13/test.js:1:1)
at /code/fast-async-issue-13/test.js:5:5
at then (/code/fast-async-issue-13/test.js:115:126)
at process._tickCallback (internal/process/next_tick.js:103:7)
at Module.runMain (module.js:592:11)
at run (bootstrap_node.js:394:7)
at startup (bootstrap_node.js:149:9)
at bootstrap_node.js:509:3
foo
async function liveBackup() {
let files = ['aaa', 'fff', 'ewrrewewrewr'];
for(let file of files) {
console.log(new Error().stack);
await Promise.resolve();
}
for(let file of files) {
await Promise.resolve();
}
return 'foo';
}
liveBackup().then(console.log);
This is really weird. After running my test after couple minutes, the sourcemaps stopped working and then on another run they worked fine (in my small test, anyway). There is something really quirky going on.
Anyway, the performance of your project is impressive but without sourcemaps this cannot be used in production. :-(
Anyway, I'm gonna close this issue and open another one.
This issue is still present in 2018 as of fast-async 6.3.0.
Can you be more specific? The example given seems to transform and work fine:
async function liveBackup(files) {
for(let file of files) {
log(await Promise.resolve(file));
}
for(let file of files) {
log(await Promise.resolve(file));
}
}
liveBackup([654,"abc",34]) ;
It seems my issue is a bit different (same error, but to do with a name collision across distinct branches of an if statement where const
is used within - perfectly valid and works correctly when fast-async
isn't involved.
I suspect it's an interaction with another Babel plugin in our project - I'll comment back here when I've figured it out.
Seems it was an issue with the ordering of Babel plugins in our project - having fast-async last fixed it.
It works fine with babel's async-to-module-method.