Step Into (F11) steps into transpiled JavaScript when debugging TypeScript that uses async/await

[jpierson]

• VSCode Version: 0.10.11
• OS Version: Windows 10
• Node Version: 4.2.2
• TypeScirpt Version:

Steps to Reproduce:

1. Set a break point on a line of TypeScript code in an async function that uses the await keyword on the Promise result of another async function. Example: const result = await callMyApi().
2. Start debugging in VS Code by selecting a related launch profile in a TypScript project. See my example snippet below.
3. Run necessary code so that the debugger is stopped on the breakpoint from step 1.
4. Press F11 to step into the callMyApi function.

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.

/// launch.json snippet
{
    "name": "Test",
    "type": "node",
    "request": "launch",
    "program": "${workspaceRoot}/node_modules/mocha/bin/_mocha",
    "stopOnEntry": false,
    "args": [
        "./bin/test/my.test.js"
    ],
    "cwd": "${workspaceRoot}",
    "runtimeExecutable": null,
    "runtimeArgs": [
        "--lazy",
        "--harmony", "--harmony_modules","--harmony_destructuring"
    ],
    "env": {
        "NODE_ENV": "development"
    },
    "externalConsole": false,
    "sourceMaps": true,
    "outDir": "${workspaceRoot}/bin"
}

// tsconfig.json compiler options snippet
{
    "compilerOptions": {
        "target": "es6",
        "module": "commonjs",
        "sourceMap": true,
        "allowJs": true,
        "outDir": "bin"
    }
   // excludes ...
}

[weinand]

@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.

[weinand]

I've added experimental support for automatically skipping code that has a source map but where the mapping does not exist and would end up in the generated code. This can be enabled in the launch config by setting an attribute smartStep to true.

@jpierson @felixfbecker please let me know if you think this is useful.

[felixfbecker]

@weinand If I understand you correctly, this is more an issue with TypeScript's/Babel's source map generation?

I have tried out the tool with your example, but compiled with the gulpfile from my debug adapter: link
You have to scroll down to the TS source because I do two-step compilation with TS+Babel. The await may not be colored, but I hover over it, it highlights the corresponding yield statement in the generator.

I think though that transpilation that adds additional function calls is quite common and if you can somehow detect and ignore those that would be a great feature. As a user, when I land in the compiled source, it is not clear to me that I have to do a step over to get to the TS again.

I tried to test the new feature by running vsce package in the repo and installing the package, but I get countless ENOENT errors like cannot read package.json or locale files, what am I doing wrong? Do I have to recompile VS Code?

[weinand]

@felixfbecker I've fixed the dependencies in vscode-node-debug and after removing node_modules and doing an npm install the vsce package created a vsix that works with the insiders release. There is no need to rebuild VS Code.

[weinand]

@felixfbecker my experimental "smart step" feature should be independent from what transpiler tools are used to generate JavaScript and source maps. The feature should just hide generated code by auto stepping through it. If you enable the feature you can see on the console how many "step in" commands were issued.

[felixfbecker]

@weinand I am still hitting the source files. Ran git pull, rm -re -fo node_modules, npm i, gulp build, vsce package and installed it

[weinand]

@felixfbecker how it should look like: https://dl.dropboxusercontent.com/u/2433608/2016-04-01%2014-23-27.mp4 (before/after)

[felixfbecker]

@weinand No idea why it's not working, can you send me your vsix?

[weinand]

@felixfbecker here is my sample project:
async.zip
and here the vsix:
node-debug-0.10.12.vsix.zip (double zipped...)

[felixfbecker]

I meant the extension file as apparently I can't get it to compile and install correctly