Since we got an early xmass gift from TypeScript team today with ES5 async/await it would be great if VSCode could better handle it. Right now running the example and pressing F10 to step over await takes us to js file
Steps to Reproduce:
"use strict";
// printDelayed is a 'Promise<void>'
async function printDelayed(elements: string[]) {
for (const element of elements) {
await delay(200);
console.log(element);
}
}
async function delay(milliseconds: number) {
return new Promise<void>(resolve => {
setTimeout(resolve, milliseconds);
});
}
printDelayed(["Hello", "beautiful", "asynchronous", "world"]).then(() => {
console.log();
console.log("Printed every element!");
});
Put breakpoint as the following:

Hoping to be able to press F10 to get to the next line but user is taken here:

Seems like ES6 target also is not working properly, user is taken here with F10:

+1 we need better async debugging support
Well, that is the next line that actually executes. Chrome devtools does the same thing. I don't think we can improve this since the debugger doesn't understand your code.
When debugging with async/await and TS, I find it really useful to set smartStep in my launch config. This will make the debugger auto-step over the JS stuff that you end up stepping into all the time.
Here is some smartStep doc: https://code.visualstudio.com/docs/editor/node-debugging#_smart-stepping
"smartStep": true makes a big difference - but it could still be better?
I'd love it to be at the level of C# debugging of async/await
@chadbr reaching the C# level of async/await debugging is difficult for a transpiled language because the runtime (debugger) only sees the generated JavaScript and the source maps have their limitations.
@weinand
The debugger doesn't have access to the same information the editors have for navigation / intelli-sense, etc.?
I'm surprised it's as good as it is ! :)
@chadbr yes, the v8-debugger used in node has no access to the language server (and is not under our control). So it does not even understand source maps.
The VS Code debug extension adds source map support on top of the debugger API. But this support is still language agnostic (and there are lots of languages that are transpiled to JavaScript).
gotcha -- need a new debugger in V8 :)
@weinand It's possible to make v8 debugger do steps until the next "relevant" instruction is met. There's a similar feature in IE that allows to omit steps in library code.
@polkovnikov-ph the "smartStep" and "skipFiles" features can be used to automatically step over "uninteresting" code. See https://code.visualstudio.com/docs/editor/node-debugging#_smart-stepping and https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_skipping-uninteresting-code-node-chrome
@weinand Yes, that's exactly what I wrote :) Thanks for linking the manual, it will be interesting for future readers.
@polkovnikov-ph aha, so with "v8 debugger" you meant the VS Code node-debugger. Sorry, I thought you referred to something else.
fwiw, I have had great luck switching to es6 for debugging -- and switching back to es5 for testing / deploy.
I also had luck experimenting with higher ES versions for the compilation target.
es6 works fine for me with the latest node 7 and 8 releases.
With higher targets the generated JavaScript looks alot like the original TypeScript.
I also experience this issue a lot. smartStep and skipFiles don't help because stepping out a line of code with await results in forwarding execution context to the end of the enclosing method within the current typescript file. So there should be more general and consistent solution.
P. S. The only workaround I've found is to set a breakpoint at the next line and continue execution (F5) till it hits the newly set breakpoint.
Does this issue also cover the same behaviour but for standard (non-async/await) Promise code? E.g.
/*paused here, step into… */Promise.resolve(1)
.then(() => {
/* step into lands here */
/* step into again… */
})
.then(() => {
/* step into lands here */
})
I tried enabling smartStep, but currently I get this behaviour:
/*paused here, step into… */Promise.resolve(1)
.then(() => {
})
/* step into lands here */
/* step into again… */
.then(() => {
})
/* step into lands here */
This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding and happy coding!
fwiw, I have had great luck switching to es6 for debugging -- and switching back to es5 for testing / deploy.
You are a genius sir, thank you
Here are my settings, if this illuminates others. Thanks to @zwhitchcox @chadbr for inspiration.
launch.json file looks like:
{
"type": "node",
"request": "attach",
"name": "Attach by Process ID",
"processId": "${command:PickProcess}",
"outFiles": [
"${workspaceFolder}/dist/*.js",
"${workspaceFolder}/dist/**/*.js",
],
"smartStep": true,
"skipFiles": [
"${workspaceFolder}/node_modules/**/*.js",
"${workspaceFolder}/node_modules/**/**/*.js",
"${workspaceFolder}/node_modules/**/**/**/*.js",
"${workspaceFolder}/node_modules/**/**/**/**/*.js",
],
"sourceMaps": true,
"protocol": "inspector",
},
Note: vscode documentations recommends
"skipFiles": [
"<node_internals>/**/*.js"
]
but doing so, skips aggressively i found.
tsconfig.json should have
//NOTE: poor debugger support for lower versions than this
//by poor I mean, skipping to .js files too often and too deep
"target": "es2017",
//since target is es2017, why not this eh! Haven't researched this enough
"lib": ["es2017"],
//this makes source map attach at the end of file rather than spamming
//seperate *.map file. This should not have any affect on debugger jumping though
//having this options as true, means the sourceMap option should not be present
"inlineSourceMap": true,
Running vscode 1.28.2 with typescript 3.5.2
Node.js 10.16.0
Most helpful comment
+1 we need better async debugging support