Debug does not work for file in symlinked folder

[bpasero]

• VSCode Version: 1.28 (master)
• OS Version: Linux Ubuntu 18

Steps to Reproduce:

1. create a symbolic link to a folder (ln -s source target)
2. open the folder (running out of master where our realpath logic is removed and you can open the link)
3. add a app.js node.js file with just one console.log statement
4. add a breakpoint
5. create a launch config:

{
    "type": "node",
    "request": "launch",
    "name": "Launch Program",
    "program": "${workspaceFolder}/app.js",
    "runtimeArgs": [
        "--preserve-symlinks"
    ]
}

6. Debug

=> 🐛 breakpoint is not hit

Works fine when opening the folder with its real path.

[roblourens]

--preserve-symlinks is simply not working here...

[bpasero]

@roblourens fyi with #18837 we no longer automatically open the resolved link as folder when someone opens a folder that is a symbolic link. This aligns with what we do in multi-root workspaces where we never resolved links.

[roblourens]

I see the same behavior with chrome devtools, this just isn't working the way I expect. Node always resolves the symlink for process.cwd() and the main script is resolved relative to that.

Maybe we can work around it for the debugger by always resolving the main script to an absolute path, if it's in a symlinked folder, and if the user has set --preserve-symlinks in their config?

[bpasero]

If it helps, fs.realpath can be used to resolve a symlink to its actual path. That is what we used to do when opening any folder. We also use it for our file watchers to convert file paths from the watcher into the format we were given (in case it is a symlink).

[roblourens]

Yeah I guess we could also always resolve paths to their real path, and advise users not to use --preserve-symlinks, but that could be a breaking change. And users might have other reasons for using it - I think it actually affects where require() looks for files. Or they want to see the right paths in stack traces.

I said that resolving the script to an absolute path would work around it but that's actually not true. The main script is still excluded from --preserve-symlinks. If you use node 10 then you can also pass --preserve-symlinks-main which does what you'd expect for the main script.

So if you use both of those flags, and we pass the script as an absolute path, then it does work.

[bpasero]

I think its fine to support --preserve-symlinks again if possible. You guys should probably update your docs because you still say that as a workaround.

[roblourens]

It should still work in the case of having a symlinked folder inside your workspace, which is what I've seen in the past, but not this scenario.

[bpasero]

Ah ok got it.

[roblourens]

I wonder if it's ok to tell people that this debug scenario only works with node 10 which supports --preserve-symlinks-main or do we need a solution for < 10 also? Is there some common scenario that drove the change to not resolve symlink paths?

[ivan-section-io]

I guess, damned if you do, damned if you don't.
VSCode resolving links had previously broken my golang editing+debugging experience, by resolving outside of the nicely constructed GOPATH those symlinks had placed everything into.

The question is: is VSCode the tool that just breaks the paths for everything (and hopes other tools will still work), or the tool that will have to cater specifically for the other "path breaking" tools?

I hope the later. But it sound like some things may have come to rely upon it... https://xkcd.com/1172/