failure to find .ts source when debugging aka inconsitency with relative { .sources } path in sourcemaps

[ilanc]

Issue Type: Bug

When trying to resolve .ts source locations and the sourcemap has relative paths e.g. "sources":["../../../src/hello.ts"] (which is the default format when you compile with tsc) then node fails to find the .ts. The error given is:
Could not load source '/src/hello.ts': Unable to retrieve source content.

It appears that node uses the HOME dir for relative paths - rather than the sourcemap directory. If you change to "./src" then you get: Could not load source '/home/ilan/src/hello.ts': Unable to retrieve source content..

Steps to repro:

git clone https://github.com/spikedata/vscode-ts-debug.git
npm i
npm run build

# ts-node = works
node -r ts-node/register src/hello.ts

# ts-node --inspect-brk = kind of works = you get the weird .js names as .ts hack
node --inspect-brk -r ts-node/register src/hello.ts

# node = doesn't work = Could not load source '/src/hello.ts': Unable to retrieve source content.
node build/main/src/hello.js

To fix node you have to do this:

edit sourcemap
change "sources":["../../../src/hello.ts"] from relative to full path (or else a path relative to ~)
e.g. "sources":["/spike/prototype/vscode-ts-debug/src/hello.ts"]
now node build/main/src/hello.js works as expected, and thankfully so does ts-node

VS Code version: Code 1.49.0 (e790b93, 2020-09-10T13:20:50.359Z)
OS version: Linux x64 5.4.0-47-generic

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz (8 x 2923)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on protected_video_decode: unavailable_off rasterization: disabled_software skia_renderer: enabled_on video_decode: unavailable_off vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	2, 1, 1
Memory (System)	15.39GB (0.56GB free)
Process Argv	/spike/v8/priv --no-sandbox
Screen Reader	no
VM	0%
DESKTOP_SESSION	ubuntu
XDG_CURRENT_DESKTOP	Unity
XDG_SESSION_DESKTOP	ubuntu
XDG_SESSION_TYPE	x11

Extensions (27)

Extension	Author (truncated)	Version
vscode-svgviewer	css	2.0.0
vue-peek	dar	1.0.2
vscode-markdownlint	Dav	0.36.3
vscode-eslint	dba	2.1.8
xml	Dot	2.5.1
gitlens	eam	10.2.2
EditorConfig	Edi	0.15.1
prettier-vscode	esb	5.6.0
vscode-statusbar-debugger	fab	2.0.6
vscode-mysql	for	0.4.0
gc-excelviewer	Gra	3.0.40
vscode-drawio	hed	0.7.2
rest-client	hum	0.24.2
json2csv	kha	0.0.1
git-graph	mhu	1.26.0
vscode-docker	ms-	1.6.0
python	ms-	2020.8.109390
vetur	oct	0.27.3
emoji	Per	0.0.3
vscode-sort-json	ric	1.18.0
LiveServer	rit	5.6.1
markdown-preview-enhanced	shd	0.5.13
stylelint	shi	0.51.0
code-spell-checker	str	1.9.0
language-stylus	sys	1.11.0
stylus-supremacy	thi	2.14.5
pdf	tom	1.1.0

[ilanc]

note: you can hack it into a state which works by using mapRoot:

"compilerOptions": {
    "rootDir": ".",
    "mapRoot": "/",

[connor4312]

@ilanc thanks for the issue. Are you using auto attach? We got a similar issue here (see the comment for the resolution) #106803

[ilanc]

Hi @connor4312 yup I'm using auto attach.

Btw a few related issues, which I would love your 2c on:

1. auto attach doesn't work for ts-node, but does for node -r ts-node/register
2. You can't set breakpoints in dependencies

The first one is not a biggie, I can easy setup an alias but the later is a real pain to deal with. I can only set breakpoints in built .js files, or singlestep into them from a breakpoint in the dependent module which Im debugging and then set breakpoints. Happy to setup a new issue to illustrate

[connor4312]

Where is which ts-node? I actually tried this out and discovered an issue on Linux with nvm...

[connor4312]

I pushed up some changes that should fix things on Linux. It'll be in the next nightly at 5PM, or if you're impatient you can install this build manually via the "Install from VSIX" command. Note that you'll need to auto attach twice to have the changes apply, as the first auto attach lazily updates the bootloader.

[ilanc]

Lekker thanks @connor4312!

BTW I've just had a look at some of your associated projects and found a random thing I didn't know about before: console.group - useful for indenting. But I digress...

What do you think about the 2nd prob - i.e. how to get breakpoints in a dependency to fire whilst debugging a dependent. I'll put a demo together and link it here.

[ilanc]

Here you go @connor4312

I've put together a demo repo: https://github.com/spikedata/vscode-ts-debug-monorepo - which is a trimmed down version of a real repo which unfortunately is private. The demo uses yarn workspaces and has 2 modules - user which depends on lib. The idea is to put a breakpoint in lib and then debug user.

I'm going to hold off submitting a new issue right now because I haven't been able to replicate the buggy behaviour which I see in my real repo - i.e. I don't hit breakpoints which I set in my dependencies when I debug a dependent app.

The demo repo is still useful in it's current state if you want to have a poke about though: it does exhibit some unexpected behaviour when debugging - i.e. vs code shows the built .js output instead of the .ts source when you hit the breakpoint. However it is actually hitting the breakpoint - whereas in my real repo I'm not hitting breakpoints in dependencies.

I've got a few theories (noted in the demo repo readme) which I will try later when time permits to see whether I can get the breakpoints to stop working in vscode.

[connor4312]

Thanks for the repo!

I think throwing ts-node in the mix is causing some issues. What's happening is that if you run user/src/cli.ts with ts-node, it gets compiled and that's all good. But the dependency is also being loaded through ts-node. Even though lib/build/main/index.js is a js file, it's still being recompiled with ts-node, and during this process ts-node replaces the sourcemap pointing back to the original .ts file with a sourcemap pointing to the already-compiled .js file. js-debug is actually following the sourcemap correctly, it's just that the sourcemap goes to the wrong place.

What I would recommend here is not using ts-node and run the compiled files directly.

You can get a pretty good experience for this by using watch tasks and launch configs. For example, you can add a tasks.json containing

Details

{
  "version": "2.0.0",
  "tasks": [
    // Compound task that runs the other:
    {
      "label": "Watch all",
      "dependsOn": ["tsc: watch - user/tsconfig.json", "tsc: watch - lib/tsconfig.json"]
    },

    // Watch tasks -- created with the `Task: Configure Task` command
    {
      "type": "typescript",
      "tsconfig": "lib/tsconfig.json",
      "option": "watch",
      "problemMatcher": [
        "$tsc-watch"
      ],
      "group": "build",
      "label": "tsc: watch - lib/tsconfig.json"
    },
    {
      "type": "typescript",
      "tsconfig": "user/tsconfig.json",
      "option": "watch",
      "problemMatcher": [
        "$tsc-watch"
      ],
      "group": "build",
      "label": "tsc: watch - user/tsconfig.json"
    },
  ]
}

And then a launch task that depends on them

{
  "type": "node",
  "request": "launch",
  "name": "Launch Program",
  "program": "${workspaceFolder}/user/build/main/cli.js",
  "skipFiles": ["<node_internals>/**"],
  "preLaunchTask": "Watch all"
}

With this, the watch tasks will get started the first time you run the "Launch Program" config, and continue running and incrementally compiling in the background. One benefit of this approach is that incremental compilation is nearly instant, and you don't get the second or two of delay that ts-node introduces for any moderately sized program.

Let me know how this works for you.

whereas in my real repo I'm not hitting breakpoints in dependencies.

Something I suspect could be happening is that your dependencies are not included in your outFiles, which defines the scope in which we will resolve dependencies.

[ilanc]

cool - thanks for that description, it clears up what's going on with ts-node. I saw that ts-node has the ability to configure where your ts-config.json lives (i.e. TS_NODE_PROJECT) but this only works for a single project, which doesn't help when debugging multiple projects at a time like this. I had settled on ts-node because of lack of requirement to build, but the second delay is annoying (my repo contains a bunch of cli tools which get run a lot and the delay grates) and the inability to debug is a showstopper.

I had been meaning to play with auto-watch (after reading this: https://medium.com/@stigi/make-vs-code-typescript-even-more-5f20f3046109). I'll try out your suggestion once the nightly is deployed - right now the .js is still giving the Could not load source.. error and the rootDir/mapDir trick doesn't work on monorepos - I get a full path in sources with the initial / missing :(

Shew ... it's becoming quite a challenge keeping up with the blog reading just to be able to debug my code. I have great hopes for https://romefrontend.dev/ ...