weinand
commented
8 years ago @jpierson this basically a problem of the generated source map and the fact that VS Code does not (yet) tries to be smart. Here is my example:
async function longRunning() {
return new Promise((resolve, reject) => {
setTimeout(() => {
resolve(42);
}, 3000);
});
}
async function main() {
const result = await longRunning();
console.log(`the answer to everything: ${result}`);
}
main();As you can see in this visualization of the generated source map, the __awaiter function has no mapping to the TypeScript source. That's the reason why VS Code shows the generated code. I think this is a good strategy because now you can clearly see that you need to do another two F11s to step into the longRunning function.
On the other hand if the source map would have a mapping for __awaiter you would end up in some strange place in the TypeScript source and you would not know how to proceed.
So the current behaviour isn't optimal but it is not buggy either. I've added a 'feature request' label.
I'm planning to make node-debug smarter by detecting the __awaiter function and automatically issuing 'step into' requests.
felixfbecker
Spown
amcdnl
Steps to Reproduce:
const result = await callMyApi().callMyApifunction.Expected Result: The .ts TypeScript file where callMyApi implementation exists should be opened and the debugger should be stopped on the first line of that function.
Actual Result: The .js transpiled JavaScript file is opened and the debugger is stopped on the first line of the that file.