To debug a Node.js process, I use:
node --inspect-brk foo_bar.js
But what if that instance would start another, separate instance, and this one would be - how to run that instance in debug mode as well?
The problem is, I am using the commander.js library for Node.js, like so:
var program = require('commander')
...
program.parse(process.argv)
This creates another instance of Node.js process, and hence I lose the debug functionality (I am debugging via Chromium browser). How can I overcome this?
Note: Commander only creates another process if you implement the subcommand using a stand-alone executable.
Commander detects debugger options being passed to the node invocation, and passes them to the subprocess with the debugging port incremented by 1.
e.g.
// index.js
const { program } = require('commander');
program
.command('sub', 'stand-alone');
console.log('1');
console.log('2');
program.parse();
// index-sub.js
console.log('3');
console.log('4');
% node --inspect-brk index.js sub
Debugger listening on ws://127.0.0.1:9229/25005682-6bf4-44fb-bdb2-2cc7749bb328
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
1
2
Debugger listening on ws://127.0.0.1:9230/00d1924a-3122-4bef-86f2-65d562fbf3ed
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
3
4
Related
Using the instructions found here I have setup Visual Studio Code to debug my nodejs code.
But it takes the debugger a few seconds to attach to node. And during that few seconds the code just runs.
So a file like this, with a breakpoint on line 1:
• 1 console.log('')
Will never break because it quits before the debugger attaches.
I can quickly ^c the code then restart and sometimes catch the debugger but this is unreliable.
Is there an event I can wait for in my code so that I know the debugger is attached and it is safe to continue?
Or is there a better configuration for doing this?
Yes, using the --inspect-brk option for node instead of --inspect.
so when running your code it would look something like this
node --inspect-brk server.js
I've got a simple nodejs program that tries to connect to NetworkManager via DBus using dbus-network-manager. Unfortunately, I can't use chrome://inspect to debug it because it behaves differently in the debugger.
Here's the code:
const NetWorkManager = require('dbus-network-manager').connect()
.then(nm => {
// this branch taken when run with or without --inspect option
console.log ('connected successfully');
})
.catch(err => {
// this branch taken when node launched with --inspect-brk option
console.log ('failed to connect, error was: ' + err);
})
And here's how it runs in 3 different scenarios:
$ node app.js
DBus test app running in development mode connected successfully
node --inspect app.js
Debugger listening on ws://127.0.0.1:9229/3fcf6bd4-f6fa-4bf2-8dcd-30c8fdcd14b8
For help see https://nodejs.org/en/docs/inspector
DBus test app running in development mode
connected successfully
node --inspect-brk app.js
Debugger listening on ws://127.0.0.1:9229/e935e8b4-0d78-4ad0-a5c1-894e5631c8fa
For help see https://nodejs.org/en/docs/inspector
Debugger attached.
DBus test app running in development mode
failed to connect, error was: Error: No introspectable
I can work around the problem given that it seems to run ok with --inspect, but I'd love to know why this is happening at all.
Thanks!
How can I just use the simple node cli/repl debugger with Jest?
The Jest documentation uses node-inspector, but it is outdated/deprecated as of Node 6.3. I tried the recommended command anyway on Node 7.7.4:
node --debug-brk ./node_modules/.bin/jest --runInBand --no-cache [your_test_file]
But this simply hangs on the following (assumedly waiting on node-inspector):
(node:13452) DeprecationWarning: node --debug is deprecated. Please use node --inspect instead. Debugger listening on 127.0.0.1:5858
I added --inspect as specified by the warning, but even then execution doesn't stop on my debugger statement in Chrome DevTools.
This seems overly complicated for a very simple use case.
I found the following command works:
node debug ./node_modules/.bin/jest --runInBand --no-cache [your_test_file]
...but with some quirky behavior. When the debugger first stops you will see:
break in node_modules/jest/bin/jest.js:10
8 */
9
>10 'use strict';
11
12 require('jest-cli/bin/jest');
debug>
Apparently Jest always injects this breakpoint so that you have time to open Chrome DevTools (irrelevant in our case since we're only going to use cli/repl).
Continue past this breakpoint with c, and after a short time (without any indication of course that things are progressing along) you should see your breakpoint:
break in webpack/assets/react/components/presentation/Feed/Comments/Comment/commentSpec.jsx:12
10 var wrapper = (0, _enzyme.shallow)(_react2.default.createElement(_comment2.default, { loading: true }));
11
>12 debugger;
13 expect(wrapper.find(_button2.default)).to.have.length(1);
14 });
debug>
The last weird thing is you need to type repl to inspect objects as described in Node Debugger and Inspecting variables using node's built-in debugger?
The combination of all these steps was not immediately obvious to me while reading the documentation, so I hope this answer helps someone get over the hurdle faster.
From node v8.4 the debugger keyword within the code is fixed for VM context. Refer this git comment.
1.Type debugger keyword in your Jest code:
describe('Testcase definition', () => {
it('should be defined with subobjects', () => {
debugger; // <-- This keyword breaks on Chrome inspect
expect(true).toBe(true);
});
});
Command to Run:
node --inspect-brk --inspect ./node_modules/.bin/jest -i tests/mytest.test.js
Now open chrome://inspect/#devices on Chrome. Voila!
How can I debug a running nodejs app? I've found tools such as node-inspector, but it seems to only support starting the app and debugging from there.
Debugging a running nodejs app.
This is the combination of a little documented feature of V8 mixed with a non-documented feature of the node.js debugger client. Say you have an already running node process that you want to debug.
# start the remote debugger in the already running node process
kill -s USR1 pid
# attach to the debugger using the node.js client
node debug host:5858
# see where you are
debug> pause
debug> bt
From there you can poke around. You can also continue and pause again to see if you seem to consistently end up in the same code area.
Debugging a nodejs app.
V8 comes with an extensive debugger which is accessible out-of-process via a simple TCP protocol. Node has a built-in client for this debugger. To use this, start Node with the debug argument; a prompt will appear:
% node debug myscript.js
< debugger listening on port 3000
connecting... ok
break in /home/username/Code/myscript.js:1
1 x = 5;
2 setTimeout(function () {
3 debugger;
debug>
cont, c - Continue execution
next, n - Step next
step, s - Step in
out, o - Step out
pause - Pause running code
Check API for other commands reference and other details
You can also use node-inspector . Use it from any browser supporting websockets. Breakpoints, profiler, livecoding etc... It is really awesome.
Install it with
npm install -g node-inspector
then run
node-debug app.js
I am trying to debug the child_process example from here using IntelliJ IDEA 12.1.3 and node 10.10. When I run nodejs app.js from a terminal everything works. The console output displays as expected. However, when I debug the same script using IDEA there are no messages in console output and the app just sits there. This is what is in the console window:
/usr/bin/nodejs --debug-brk=58954 app.js
debugger listening on port 58954
debugger listening on port 58954
When I run the script in IDEA without the debugger attached, the script works as expected.
Why does attaching the debugger break the script?
You can force the children to use a free port for debugging. InteliJ will automatically pick up the port chosen by the child process.
Here's an example:
// Determine if in debug mode.
// If so, pass in a debug-brk option manually, without specifying port.
var startOpts = {};
var isInDebugMode = typeof v8debug === 'object';
if(isInDebugMode) {
startOpts = {execArgv: ['--debug-brk']};
}
child_process.fork('./some_module.js', startArgs, startOpts);
looks like a bug in node.js fork to me: both parent and child processes receive --debug-brk=58954 switch and attempt to start debugger and listen port 58954.