Vscode: Feature request: Debug typescript with ts-node

[sandangel]

• VSCode Version: 1.10
• OS Version: Arch linux x64
  Is there any way to debug typescript file without compile it to js? I found ts-node package which can run typescript file directly in node environment, but I cannot config vscode to use it in debuging like this:
  "runtimeExecutable": "/path/to/ts-node",
  "outFiles": [
  "${workspaceRoot}/*/"
  ]

[mjbvz]

@roblourens can you please take a look at this issue?

@sandangel Can you explain the usecase for this request as well? Are you just trying to avoid generating the *.js files?

[roblourens]

I assume that ts-node would just transpile TS in memory and run node under the hood with whatever args you pass to it. In that case, what you tried looks correct to me. They might not produce sourcemaps though, I have no idea. What problem are you having? Please be more specific.

[jgoz]

I assume that ts-node would just transpile TS in memory and run node under the hood with whatever args you pass to it. In that case, what you tried looks correct to me. They might not produce sourcemaps though, I have no idea. What problem are you having? Please be more specific.

ts-node does produce sourcemaps, but I think the problem is that the JS output and sourcemaps are being written (by default) to a temporary directory with hashed file names. You can override the cache directory, but cannot disable the filename hashing. I'm assuming VSCode depends on the JS/map filenames matching the original TS sources, but I may be wrong on that.

But rather than making VSCode work for the particular internals of ts-node, it might better to support reading sourcemap information from source-map-support. ts-node exposes cached sourcemap information to source-map-support; if VSCode was somehow able to request sourcemap data from source-map-supprort, this might allow debugging with any compile-to-js language that has a node wrapper.

Note that I have a pretty shallow/incomplete understanding of the VSCode side of things, so my assumptions above may be completely wrong.

[jgoz]

Can you explain the usecase for this request as well? Are you just trying to avoid generating the *.js files?

I'm not @sandangel, but that is the use case I'm interested in. We run webpack-dev-server with a typescript loader, so no JS files are being written to disk. Being able to debug unit tests directly with ts-node would avoid having to run a tsc watcher just for that.

Definitely not a show-stopper.

[roblourens]

That source-map-support package is interesting, thanks for the link. VS Code doesn't care whether the output file names are hashed, we just need the sourcemap info to be correct, and I don't see any reason why ts-node can't do that now - and maybe it is. If someone can try again with "protocol": "inspector" in your launch config, that works with different sourcemap setups more often. If it still doesn't work, keep "inspector" and enter .scripts in the debug console during a session. That will output all the sourcemap info that VS Code knows about the files being debugged.

[sandangel]

I'm developing a node app. I just think that when developing, you have to compile the code many many times, using compile tools, and watching for file changes. If there is a way using ts-node or somethings like that to debug with vscode when developing, and when you finish, you just have to built the code once. It would be great.
@roblourens I tried with that config but it not worked. I still have to run tsc / tsc -w before start debuging. It just not throw error with .vscode/launch.json file

[sandangel]

And in the Sever side, do we have to transpile ts code to js while we can execute it directly with tools like ts-node? If we don't, why do we still have to transpile ts to js just for debugging?

[jgoz]

@roblourens I actually got your suggestion to work, debugging mocha tests with ts-node. This is my launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Mocha Tests",
      "cwd": "${workspaceRoot}",
      "env": {
        "TS_NODE_CACHE_DIRECTORY": "${workspaceRoot}/.ts-node"
      },
      "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/mocha",
      "runtimeArgs": [
        "--no-timeouts",
        "--colors",
        "--compilers", "ts:ts-node/register",
        "${workspaceRoot}/src/*/*.tests.ts"
      ],
      "protocol": "inspector",
      "sourceMaps": true,
      "outFiles": ["${workspaceRoot}/.ts-node/**"]
    }
  ]
}

Observations:

• "inspector" was able to pick up the cached sourcemaps from the path I specified, but "legacy" was not
• I had to set "runtimeExecutable" to mocha's executable (rather than "program"), otherwise the tests would not start with "inspector" (this was true regardless of whether I used ts-node)
• Debugger did not automatically detach after the program had completed (again, was true regardless of ts-node being used)
• Test execution was painfully slow, probably because the typescript compiler is being invoked in with the inspector attached

[roblourens]

Great! Glad you got it to work.

I had to set "runtimeExecutable" to mocha's executable (rather than "program"), otherwise the tests would not start with "inspector" (this was true regardless of whether I used ts-node)

Yeah, Mocha likes to spawn a new process for the tests unless you do something like this.

Debugger did not automatically detach after the program had completed (again, was true regardless of ts-node being used)

This is a limitation of the 'inspector' protocol debugger that we can't work around right now.

[chadbr]

fwiw, @jgoz's solution seems to work for me - thanks!

[dupski]

Hey all, I just did a load of research on this and have documented a very simple solution in the ts-node repo
https://github.com/TypeStrong/ts-node/issues/46#issuecomment-296895962

Sample Project here