Debug should resolve symbolic links for breakpoints

[JoshuaFox]

A breakpoint works when set on the exact same line in one VS Code tab but not in another.

There seem to be two ways of opening a Javascript file, and if the full path appears in the tab, then breakpoints work.

But if the filename only appears in the tab header, then breakpoints all become Unverified (gray; disabled) during execution.

If you open using CTRL-P, then both variants are usually available.

VS Code 1.36.1, Node 8.16.0, running Mocha tests.

[IllusionMH]

Looks like VSCode can't map your project files to files that are reported by node.

Do you have proper values for runtimeArgs, cwd, outFiles etc. for your scenario?
https://github.com/Microsoft/vscode-recipes has recipes for different cases (including Mocha)

[JoshuaFox]

Note also that the two variants of each file are treated separately in the debugger, as if they are different files. In this screenshot, each breakpoint was set in the different variant, and as you see the first is disabled.

[JoshuaFox]

  VSCode can't map your project files to files that are reported by node.

Right, but sometimes it can, as described.

runtimeArgs, cwd, outFiles

In launch.json,  runtimeArgs was OK.

• cwd was not there, but adding the literal  path (or ${workspaceFolder} makes no difference.
• As to outFiles, there is no transpilation, but in any case, adding the workspace folder as outFiles makes no difference.

{
	"version": "0.2.0",
	"configurations": [
		{
			"type": "node",
			"request": "launch",
			"name": "Launch via NPM",
			"runtimeExecutable": "npm",
			"runtimeArgs": [
				"run-script",
				"debugTest"
			],
			"port": 9229,
                        //cwd makes no difference, whether as literal or as variable.
			"cwd": "/full-workspace-path",
                        //outFiles likewise makes no difference.
			"outFiles": [ "${workspaceFolder}" ]

		}
		
   ]
}

[isidorn]

Looks like a duplicate of #12448
Assigning to @weinand and @bpasero to potentially close as duplicates

[JoshuaFox]

I am using Ubuntu 18.04.2, so I guess it is not a matter of case-insensitivity.

[IllusionMH]

@isidorn not sure if this one is related to #12448

@JoshuaFox try use configurations from recipe for mocha instead of launching npm script.

It still looks more like a question than actual issue with VSCode.

[JoshuaFox]

I tried that Mocha recipe, and the tests run, but the same breakpoint issue occurs.

than actual issue with VSCode.

Quite possibly. The puzzle is why this is happening.

[bpasero]

It is easy to find out if this is #12448 by going to each tab and copying the full absolute path (from the context menu) and then comparing the 2 paths for differences.

[JoshuaFox]

You got it! The two variants' full paths are /home/joshua/hdd/more-dev/myworkspace/myfile.js /hdd/more-dev/myworkspace/myfile.js (I have a symbolic link from my home /home/joshua/hdd/ to target /hdd.) When I open the workspace folder using the link path (under home), and do CTRL-P to get a file, I see those two variants. Also, the Explorer gives me the "buggy" variant. . The buggy variant is the one under the opened workspace folder (the link path, under home)! On the other hand, the variant at the non-link path is the one that allows breakpoints! Symbolic links are a normal feature of Unix and should be supported.

[isidorn]

This sounds like a feature reuqest that we should resolve symbolic links for breakpoints. Which we do not do atm.
I do not have this on my plan to tackle this, thus assigning to backlog.

[JoshuaFox]

A fix is not urgent for me now. But it seems to me that having a directory tree under a symbolic link is quite ordinary in Linux, as is opening a workspace inside such a tree. In fact, I would expect applications to work with paths as given, so I am surprised that VS Code is going through the extra step of resolving symbolic links, and using those for its breakpoint path (which also showing the path-as-given as a second variant).

[weinand]

VS Code cannot provide symbolic link support for breakpoints by itself. It is the underlying runtime that has to support symbolic links.

In case of node.js you can enable this by adding a flag.
See https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_can-i-debug-if-im-using-symlinks for details

And there is a discussion here: #57954.

/duplicate #57954

[vscodebot]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!