Integration with node-inspector

[nsipplswezey]

node-inspector is the default node debugging tool.

Adding support for node-inspector is a cool idea.

It requires either a new CLI command for starting in debug mode.
Or adding a --debug flag to nodal s which instead of running node cluster.js will run node-inspector cluster.js

The other useful thing would be to figure out if there are some options for node-inspector that specify that tabs should be opened on all cluster ports by default.

Idea originated from a gitter question; copy/paste here for reference:

Question:
@keithwhor I'm using node-inspector, but when I put a break point in the controllers, node-inspector does not stop. When I put a debugger in the controller, the execution does stop, but node-inspector does not catch it. Do you have any ideas?

Response:
Idea: it depends on how you're starting your nodal server. By default nodal s just ends up running npm run start which if you look in your package.json the npm start command just corresponds to node cluster.js You'll notice that cluster.js is a little different than a single node process. If your use case is just the default run command, then you're not setting the debugger up to handle just one node process; instead your looking to debug a cluster of processes.

See here: node-inspector/node-inspector#130
That issue doesn't resolve the problem, but instead just points at a blog post with some more info here:
https://strongloop.com/strongblog/whats-new-nodejs-v0-12-debugging-clusters/

It's a bit messy, and that blog post pitches some strong-loop tool... but here's the important bit:

The fix was to assign each worker a debug port offset from the master’s by the worker ID. In effect, the master port is 5858, the first worker is 5859, the second is 5860, etc.

...

Note that the URL you’ll get, should be something like:

http://localhost:8080/debug?port=5858

I gave this a shot with the following:

1. Run node-debug cluster.js
2. Open up a new tab for each cluster process

http://127.0.0.1:8080/?port=5858
http://127.0.0.1:8080/?port=5859
http://127.0.0.1:8080/?port=5860
http://127.0.0.1:8080/?port=5861
http://127.0.0.1:8080/?port=5862

1. Set breakpoints in each of them. This is kind of tedious, and would make me hesitate to use this debugging approach as my main strategy for developing my API. But it's useful to know you have it if you need it.
2. Make your API request.
3. node-debug will alert you to which particular breakpoint, in which specific process you hit, and you.

Or at least that's what did it for me.

I'll open an issue to add a --debug flag to nodal s command that launches nodal using this approach.

I think this could explain why you're getting irregular behavior using node-inspector.

[nsipplswezey]

Gave this a shot in my global install of nodal.
Mostly leaving these notes for myself, but also anyone who's curious..

Got up and running by

1. Adding a debug command to package.json.jst in the cli/templates which just does a nodal-debug cluster.js

On a fresh demo project npm run debug works as expected.

1. Copying the s.js command into a debug.js comand in the cli directory, and replacing .

      let child = spawn('npm',  ['start'], {stdio: 'inherit'});

with

      let child = spawn('npm',  ['run', 'debug'], {stdio: 'inherit'});

nodal debug then worked as expected.

Ran into two problems which I'll have to look at more closely:

-When I added a step to install node-inspector, I expected the command to be ignored on my machine since I already have node-inspector installed. But it ran anyway. The better solution is to check if node-inspector is installed, and install it conditionally or something.

-Somewhere along the way I interrupted node-inspector's boot up and exited the process. And after that node-inspector stopped opening up a separate chrome instance. I'll have to figure out why.

Things to look into next:

And easy way to detect if a package is already installed, and if it's not installed, alert the user, or install it. I bet there's an example in the cli directory to follow.

What the desired outcome is for node-inspector. Ideally it should open a tab for each process which is running on each port.

[nsipplswezey]

This is a minor issue, but a potential enhancement.

npm packages that expose a CLI are typically installed globally.

node-inspector is just a package.

Folks have pointed out that there are some downsides to the over-use of global NPM dependencies; particularly version management.
The TL;DR is: global dependencies are fine for certain use cases, but can be abused
http://www.sitepoint.com/solve-global-npm-module-dependency-problem/

I think Nodal as a global package falls into the category of appropriate use cases.

As I'm looking into integrating node-inspector into Nodal to facilitate Nodal server debugging, one approach is to expect the user to have a global install of node inspector. I better approach I think would be to install node-inspector locally –as needed– and use the local version through an npm script.

npm has long exposed an interface to allow developers to use the CLI exposed by npm modules using a locally installed module.
http://4waisenkinder.de/blog/2014/10/18/npm-2-dot-0-and-the-much-better-star-npm-run-star-command/

This would be the first time that the relatively clean and simple package.json file would grow to handle a new concern: presenting an interface to the CLI of a locally installed package.

Conversely Nodal exposes it's own CLI, so the perhaps better alternative would be to handle this not at the npm script level, but at the Nodal CLI level.

[nsipplswezey]

After some experimenting:

Best cleanest option is to just implement the debug command in a form parallel to the test command and add a node-inspector dependency.

Reduces necessary commands to:

npm install
npm run debug

Fires up a nice debugger. Clean. Done.
Will require a short guide, likely a cleanup of the first post in this issue, to describe the approach to debugging a cluster.

Notes for later discussion:
v8_inspector is coming down the pipe.
nodejs/node#2546
https://github.com/repenaxa/node/tree/v8_inspector

[keithwhor]

Going to but this on the backburner for now. Will figure something out after looking at it more in-depth.

[nsipplswezey]

While this issue is closed, I'd like to use it as a reference for any effort to set up a debugging environment for building Nodal servers. Nodal users are asking for it.

Ultimately, there should be a non-worker based startup of the nodal server. The dominant usecase for node-debug is not debugging cluster logic.

Latest update is that the instructions in this thread seem to get a debugging session up and running.
Then the debugger seems to pause on an exception on port 5858.
After you step through that exception, you can then open up a session on 5859, which then seems to pause on the same exception. After stepping through that, the debugger then detaches.

Here's where the debugger stops:

And the detach error message:

Here's the error message from the console running node-inspector:

Nicolass-MacBook-Air:node-debug-tldr nsipplsw$ npm run debug

> [email protected] debug /Users/nsipplsw/node-debug-tldr
> node-debug cluster.js

Node Inspector v0.12.8
Visit http://127.0.0.1:8080/?port=5858 to start debugging.
Debugging `cluster.js`

Debugger listening on port 5858
[Nodal.Daemon] Startup: Initializing
[Nodal.Daemon] Startup: Spawning HTTP Workers
Debugger listening on port 5861
Debugger listening on port 5859
Debugger listening on port 5862
Debugger listening on port 5860
[Nodal.84065] Startup: Starting HTTP Worker
[Nodal.84065] Ready: HTTP Worker listening on port 3000
[Nodal.84065] Shutdown: Exited with code 1
[Nodal.Daemon] Error: bind EADDRINUSE null:3000
Error: bind EADDRINUSE null:3000
    at Object.exports._errnoException (util.js:896:11)
    at exports._exceptionWithHostPort (util.js:919:20)
    at cb (net.js:1311:16)
    at rr (cluster.js:620:14)
    at Worker.<anonymous> (cluster.js:590:9)
    at process.<anonymous> (cluster.js:750:8)
    at emitTwo (events.js:111:20)
    at process.emit (events.js:191:7)
    at handleMessage (internal/child_process.js:718:10)
    at Pipe.channel.onread (internal/child_process.js:444:11)