Closed Rush closed 8 years ago
I'm a little tied up with the day job, but I'll try and look at this at the weekend
Thank you sir, I appreciate it. Have a good day. :)
This appears to be a babel thing - when I get nodent to display source maps, it works every time:
node_modules/fast-async/node_modules/nodent/nodent.js --sourcemap test.js
Error
at Object.<anonymous> (/Users/matthewwoolf/git/fasy-async-sourcemaps-test/test.js:5:17 => …test.js(original):6:12
at then (eval at <anonymous> (/Users/matthewwoolf/git/fasy-async-sourcemaps-test/node_modules/fast-async/node_modules/nodent/lib/runtime.js:1:80), <anonymous>:3:2066)
(NB: I edited the code to reduce it to the test case, so the line number is different. Also, nodent prints the executed and original line numbers)
When I tell babel not to cache stuff, it fails every time:
BABEL_DISABLE_CACHE=1 node run-fastasync.js
So this seems to be related to Babel's caching mechanism. I'll see what I can find out, but I'm not a Babel expert and the plugin certainly doesn't tell it to do anything with caches or sourcemaps
Ok, there seems to be a bun-fight between nodent and Babel over who should do the stack trace mapping. The fix is to supply the dontMapStackTraces
flag to nodent. My .babelrc-fastasync now looks like:
{
"presets": ["es2015"],
"plugins": [["fast-async", {
"compiler": {
"sourcemap": true
},
"env":{
"dontMapStackTraces":true
}
}]]
}
...and all looks OK.
Then I guess these should become the default?
Probably. I'll update it in the next minor release. Did it fix your issues too?
I'm hoping that this fixed your issue, so I'll close this. Please re-open if I'm wrong
To reproduce the second:
You will see both first and second run:
In contrast the bluebird version works fine: