-
Notifications
You must be signed in to change notification settings - Fork 28k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debug does not work for file in symlinked folder #57954
Comments
|
@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. |
I see the same behavior with chrome devtools, this just isn't working the way I expect. Node always resolves the symlink for 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 |
If it helps, |
Yeah I guess we could also always resolve paths to their real path, and advise users not to use 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 So if you use both of those flags, and we pass the script as an absolute path, then it does work. |
I think its fine to support |
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. |
Ah ok got it. |
I wonder if it's ok to tell people that this debug scenario only works with node 10 which supports |
I guess, damned if you do, damned if you don't. 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/ |
Do we know how common this scenario is for node developers? My gut says not that common. I still don't have a < node 10 solution. |
one common scenario is "npm link": using an npm module under development in node.js project (e.g. the vscode-debugadapter). |
Debugging with a linked npm module still works. What doesn't work is when the main script itself is inside a symlinked path. Node is treating the main script differently from other scripts. |
The best fix I have is to detect when the cwd is in a symlinked path, and if so, always use an absolute path instead of resolving it to a relative path. This is needed because I'll update the docs to tell users when to use |
@roblourens so what is the full fix for this? I need:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"program": "${workspaceFolder}/index.js",
"runtimeArgs": [
"--preserve-symlinks",
"--preserve-symlinks-main"
]
}
]
} ? |
Correct |
Steps to Reproduce:
ln -s source target
)realpath
logic is removed and you can open the link)=> 🐛 breakpoint is not hit
Works fine when opening the folder with its real path.
The text was updated successfully, but these errors were encountered: