I'm using VSCode to debug a node.js script running on a remote linux server on my LAN. I'm using the RemoteSSH plugging to access the scripts, save, and edit it. I can also run it from the VSCode just fine. But I tried to use this article here to setup remote debugging:
https://dakshika.medium.com/remote-debug-node-js-application-using-visual-studio-code-dc0fa0b4dec4
I did modify the commandline command to start the node.js debugger since my server has an older version of Node (Node 8.10.0). I have to use the following:
node --inspect-brk=127.0.0.1:9229 scripts/myScript.js
After running the command, it shows that node is listening for connections. But when I run my Attach launch configuration:
"version": "0.2.0",
"configurations": [
{
"name": "Attach",
"type": "node",
"request": "attach",
"port": 9229,
"address": "127.0.0.1",
"restart": false,
"sourceMaps": false,
"continueOnAttach": true,
"localRoot": "${workspaceRoot}",
"remoteRoot": null
}
]
it doesn't do anything. The run/pause/stop buttons come up but it doesn't jump to the first line of code so I can step through. Any idea what could be going on?
Related
I have docker compose in a linux machine. The docker images are build out of node JS source code sitting in the same machine. My IDE is VS Code, but it is running on a different machine(Windows). I have configured Remote SSH so that the IDE in windows machine can browse through the source code in the linux machine using SSH connection. This setup is working fine for me.
But I have a need to do remote debugging of the app running in the docker. I am able to attach the debugger to the process, but when I add break point, it says 'Unbound breakpoint'. I think it is because the debugger is unable recognise the source code sitting in the remote machine.
The following is the launch.json config:
{
"type": "node",
"request": "attach",
"name": "Test",
"protocol": "auto",
"port": 4001,
"restart": true,
"localRoot": "${workspaceFolder}",
"remoteRoot": "/src",
"skipFiles": [
"<node_internals>/**/*.js"
]
}
How can add a properly 'bound' break point?
I get error:
Cannot connect to runtime process, timeout after 10000ms - (reason: cannot connect to the target)
NodeJs v4.3.1 run on WSL.
The below is my launch.json
"type": "node",
"request": "attach",
"name": "Attach to WSL",
"port": 3000,
"address": "localhost",
"restart": true,
"protocol": "inspector",
"localRoot": "${workspaceFolder}/web-frontend",
"remoteRoot": "/mnt/c/workspace/.../web-frontend"
WSL uses the path from Windows so localRoot and remoteRoot are the same.
What am I missing so far?
I created a VS Code extension: WSL workspaceFolder, which will help you to automatically set the remoteRoot in your launch.json to the correct WSL path. For example my launch.json, based upon your file paths would look like below;
/vscode/launch.json
{
// 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": "attach",
"name": "Attach to Remote",
"address": "localhost",
"port": 5858,
"localRoot": "${workspaceFolder}/web-frontend",
"remoteRoot": "${command:extension.vscode-wsl-workspaceFolder}/web-frontend"
}
]
}
Then to start a debug session, in the WSL terminal enter NODE_ENV=debug node --nolazy --inspect-brk=5858 before the path to the script you wish to debug.
However, you may run into problems using Node v4 because it does not support the 'inspector protocol'. I would strongly recommend you upgrade to a more recent version of Node. Currently v8 is the latest LTS version: Node.js releases
I am trying to get VSCode 1.20.1 to break at a breakpoint in my project, but it simply refuses to break (at least with the inspector protocol). I've distilled this down to a 3 line Node.js sample project which can be found here on GitHub, I'll paste the relevant sections below.
The index.js program is a simple Hello World with a delay to avoid any debugger attach races (more on that later).
setTimeout(() => {
console.log('Hello'); //Breakpoint is set here
}, 5000);
The launch.json is below:
{
// 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": "Normal Run",
"runtimeExecutable": "${workspaceFolder}/bin/node",
"runtimeArgs": [
"--nolazy",
"--inspect-brk=0.0.0.0:5858"
],
"program": "${workspaceFolder}/index.js",
"args": [],
"env": {
"DOCKER_ARGS": "-p5858:5858"
},
"address": "127.0.0.1",
"port": 5858,
"timeout": 60000,
"console": "integratedTerminal",
"smartStep": true,
"stopOnEntry": false,
"protocol": "inspector",
"autoAttachChildProcesses": true,
"localRoot": "${workspaceFolder}",
"remoteRoot": "/src"
}
]
}
Note that Node.js is running in Docker in the standard node:8 container with a volume mount of the local source directory (that is what the runTimeExecutable is for, see GitHub). If I use Wireshark to monitor port 5858, I can see the debugger attach and decode all messages. Strangely, VSCode issues the Runtime.runIfWaitingForDebugger immediately, and then later issues the Debugger.setBreakpointByURL message that seems to be accepted by Node.js (it successfully returns a Location for the breakpoint). I have the 5 second timeout in the code just in case this race is the cause of the problem (which it does not seem to be).
As an aside, if I use my host Node.js (6.11.4) with the protocol as legacy (or auto which chooses legacy) and comment out the runtimeArgs, runtimeExecutable, etc. VSCode hits the breakpoint. If I force the protocol to inspector (which is experimental in 6.11.4) and add back the runtimeArgs (but not executable) the debugger attaches but no breakpoint is hit, essentially the same behavior as with the Docker node:8 above.
What am I doing wrong here? This problem originally started in a new TypeScript project using sourcemaps and mocha, etc. but I've boiled it down to this.
I'm using that repo https://github.com/SimulatedGREG/electron-vue
and trying to set up VS Code debug configurations like this
{ //main
"name": "Attach",
"type": "node",
"request": "attach",
"port": 5858,
"sourceMaps": true
},
{
"name": "Debug Renderer Process",
"type": "chrome",
"request": "attach",
"url": "http://localhost:9080",
"webRoot": "${workspaceRoot}/src"
}
and got messages like
Invalid responce {
"description": "node.js instance",
"devtoolsFrontendUrl": "chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:5858/0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e",
"faviconUrl": "https://nodejs.org/static/favicon.ico",
"id": "0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e",
"title": "node",
"type": "node",
"url": "file://",
"webSocketDebuggerUrl": "ws://127.0.0.1:5858/0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e"
}
for main and
connect ECONNREFUSED 127.0.0.1:9229
for render processes.
I know that both main and renderer procs are served by webpack 3 and webpack-dev-server 2 but cannot find debug configurations.
Debugging main process using Chrome using link like chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:5858/6c1d575a-d0f6-4ffa-9465-065ebc3d302c works but want to use VS Code.
What am I doing wrong? Can somebody share debug configurations for VS Code or WebStorm?
So this was a real pain to figure out, mainly because the vue electron boilerplate does some in-house management of the main and renderer process. The first challenge is to attach to the child process (main) as reliably as possible. The second challenge is to make sure breakpoints persist across sessions and things like that. This answer doesn't focus on the renderer process at all, because you can just debug that in the devtools console.
Put these two configurations in your launch.json, and add --no-lazy to the dev script in package.json to fix breakpoints. If you're just looking for the solution, you can probably stop reading here. If it didn't work, keep on reading.
{
"type": "node",
"request": "launch",
"name": "Electron: Main (npm)",
"cwd": "${workspaceFolder}",
"outFiles": ["${workspaceFolder}/**/*.js"],
"runtimeExecutable": "npm",
"runtimeArgs": ["run-script", "dev"],
"outputCapture": "std",
"smartStep": true,
"sourceMaps": true,
"protocol": "inspector",
"port": 5858,
"timeout": 20000
},
{
"name": "Electron: Main (attach)",
"type": "node",
"request": "attach",
"cwd": "${workspaceFolder}",
"outFiles": ["${workspaceFolder}/**/*.js"],
"skipFiles": ["init.js"],
"smartStep": true,
"sourceMaps": true,
"protocol": "inspector",
"port": 5858,
"timeout": 20000
}
The first one can be executed with no additional actions needed. It will run the script via npm, and attach directly to the sub process with inspect port 5858.
The second script lets you run npm run dev from a terminal, and then attach. It may be convenient to use this one, if you're more used to it.
Now I will explain why I have used all the settings, in case things change and you're wondering if this is outdated.
"cwd": "${workspaceFolder}",
I could not reliably run the session without doing this. It still worked sometimes though.
"outFiles": ["${workspaceFolder}/**/*.js"],
I could not debug any files without this on.
"outputCapture": "std",
I did not get any output from dev-runner.js if I didn't have this set.
"smartStep": true,
When I restarted the session (especially using the npm variant), the breakpoints got unset and black. This option actually fixed it, but looking an this issue, I suspect you shouldn't normally have to use this option.
"sourceMaps": true,
If you're seeing gibberish code, you may want to add the following:
/**
* Adjust mainConfig for development settings
*/
if (process.env.NODE_ENV !== 'production') {
mainConfig.devtool = 'source-map' // <- THIS
mainConfig.plugins.push(
new webpack.DefinePlugin({
__static: `"${path.join(__dirname, '../static').replace(/\\/g, '\\\\')}"`
})
)
}
This option helps with that.
"protocol": "inspector",
Might as well. Legacy doesn't work.
"port": 5858,
This is the port of the child process, spawned by dev-runner.js
"timeout": 20000
Since we're waiting for a child process to finish spawning, it may take longer than 10 seconds to launch and then attach. I set it to 20 seconds, but you are free to lower it if your PC is fast enough. (default is 10s)
Further references in the world of bleeding edge software.
VS Code version: 1.21
Electron version: 1.8.7
Chromium: v59
Node: 8.2.1
you may need to use new inspect protocol in vs code with latest electron binary. It'll looks like
{
"type":"node",
"request":"launch",
"name":"Electron Main",
"runtimeExecutable":"${workspaceRoot}/node_modules/.bin/electron",
"args":[
"${workspaceRoot}/main.js",
"--remote-debugging-port=9333" //Set debugging port for renderer process
],
"protocol":"inspector" //Specify to use v8 inspector protocol
}
important piece is you are specifying protocol to use inspect instead of old node debug. I've wrote summary around this while ago at https://kwonoj.github.io/en/post/multi-target-dbg-electron-vscode/ .
TL; DR
On Microsoft VSCode v1.6.1, how to:
Properly set runtime executable?
Properly pass Heroku arguments?
Run Heroku Node.js app?
Debug Heroku Node.js app?
Details
I have created a Heroku Node.js application, which is launched using the CLI command:
heroku local web
and successfully starts at port 5000.
I am trying to debug it using Microsoft Visual Studio Code, using the following launch.json configuration:
{
"name": "Launch",
"type": "node",
"request": "launch",
"program": "${workspaceRoot}/app.js",
"stopOnEntry": false,
"args": [],
"cwd": "${workspaceRoot}",
"preLaunchTask": null,
"runtimeExecutable": "/usr/local/bin/heroku",
"runtimeArgs": [
"local web",
],
"env": {
"NODE_ENV": "development"
},
"console": "internalConsole",
"sourceMaps": false,
"outFiles": []
}
But VSCode is automagically passing --debug-brk argument to heroku, causing the error:
/usr/local/bin/heroku --debug-brk=23080 'local web' app.js
! `--debug-brk=23080` is not a heroku command.
! See `heroku help` for a list of available commands.
VSCode also does not find heroku command without its full path (seems like it is not loading PATH environment variable).
Any ideas about how to setup the editor?
The following solution works for me:
1) In your procfile add the parameter --debug to the node process
web: node --debug server.js
By default the debugger listens in the port 5858
2) Once you have the node process running, open VSCode and add the following configuration to your launch.json file
{
"type": "node",
"request": "attach",
"name": "Attach to Process",
"port": 5858
}
3) Finally, click the play button in VSCode with the option "Attach to Process" and it should debug your process.
The following solution worked for me.
In my package.json "scripts", I added:
"debug": "node --inspect-brk server.js"
Then, in launch.json I added an envFile entry to the default "Launch via NPM" configuration, which now looks looks like this:
{
"type": "node",
"request": "launch",
"name": "Launch via NPM",
"runtimeExecutable": "npm",
"runtimeArgs": [
"run-script",
"debug"
],
"port": 9229,
"envFile": "${workspaceFolder}/.env"
}
The above solution enables the VSCode debugger to run my server via an npm script, and my server runs with the env vars set in my .gitignore'd .env file, just like in the "regular" Heroku node.js workflow.
I struggled with this as for some reason the solution propsed didn't work for me. However, an alternate solution did so I thought I would share.
From the default debugging options in VS Code choose
Attach by Process ID
When you start the debugger with this configuration it should list available processes to attach to and one should be simply be server.js. This requires manually attaching each time, and if the other automatic attachment works for you that may be better, but this is still a workable solution.