Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 603 Vote(s) - 3.53 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How to PROPERLY debug node.js with node inspector?

#1
I have an app built in node.js and I use the node inspector in order to debug.
But it's quite hard because of this:

1. My breakpoints are never saved after I restart the server
2. I cannot put a breakpoint on a file that has not loaded yet; so I have to step into from the first script to the one I want; REALLY PAINFULL!

How do you really debug node.js with node inspector?

The videos on how to use node.js are quite misleading as everything is into a module...


or this one the scripts appear are already loaded in the first script



## Edit: ##
Nobody can answer this question? :s
Reply

#2
Try using IntelliJ WebStorm - there's a free trial and licenses aren't outrageously expensive. It lets you save breakpoints in all your files prior to starting up its own internal node process and remembers them across process restarts.

I agree - node-inspector looks brilliant, but is quite useless unless your app has a clear place to set a breakpoint in the top level script just after your source files have loaded, but before you hit the area you want to debug. You can structure your own code this way, but you won't be so lucky with other helpful libraries you want to include. Also... why should a debugging tool dictate your project structure!

Forgetting breakpoints is extremely unhelpful... most of my debug runs take more than one walkthrough, as in other people's code it's easy to step past where you want to be.
Reply

#3
You can use node-codein for inspection. It won't do runtime breakpoints but it should ease the inspection process.

[To see links please register here]


Reply

#4
The problem with client-side breakpoints is that it's hard to keep track of the breakpoint position when the file changes. Unlike in an editor, it cannot keep track of lines being changed, etc.

@RyanOlds suggestion of using debugger; statements is also a good one, but you have to make sure the debugger is connected before the statement is evaluated, because it is ignored otherwise. Starting with --debug-brk is a good way to force this, because the execution is paused on the first line allowing you to attach the debugger and then continue the execution.

You could try debugging with node's [internal debugger](

[To see links please register here]

).

Edit: However, according to the [v8 DebuggerProtocol](

[To see links please register here]

) it's possible to set breakpoints on script that hasn't been loaded yet AND you can set breakpoints by function, script and more. It should therefore be possible for node-inspector to keep track of your breakpoints (in a session, or whatever). It doesn't do so right now, though.

Maybe if v8 allows a certain piece of code to trigger a breakpoint, similar to nodes *debugger*?
Edit: It does, you should be able to trigger a break by throwing any old exception (caught or uncaught).
Reply

#5
The new version (0.3.x) of node inspector saves breakpoints in browser's local storage and restores them automatically.

[To see links please register here]

Reply

#6
Also worth noting.. vscode has a great debugger for node.

[To see links please register here]


Available on Mac, Linux, & Windows.

It does runtime breakpoints (without the need of writing debugger; statements),
supports variable watches, and even has a call stack window (very nice).

Everything is so automated, it is now my goto over sublime text when using nodejs (and I LOVE sublime).
Reply

#7
This is built in now **including saving breakpoints**. I just tested it in node 7.3.0.

```node --inspect --debug-brk app.js```

This prints a url like this

```To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/c3d5d93e-9d27-41b9-a4da-607e43c9d4f8```

Put that in Chrome and you're good to go.

If you want to skip copy/pasting the url, do this:

```npm install -g inspect-process
inspect --debug-brk app.js
```

Unfortunately the `inspect-process` method doesn't retain the breakpoints :-(.

Here's a video I made:

Reply

#8
In javascript you can set breakpoints using the `debugger;` statement. However, they will only pause node if a debugger is actually attached.

So launch your node script using

node --debug-brk myfile.js

then launch node-inspector and press the play button to continue to the next breakpoint and it will hit your `debugger;` breakpoint (at least that works for me ATM)

*(as noted in the comments: in recent versions of node you no longer have to separately install node-inspector. If you launch node using `node --debug-brk --inspect myfile.js` you get a url that launches the debugger in your browser).*

you still need one extra click after restarting, but at least your breakpoints are saved.

if your breakpoint is not hit automatically, but only after some user action you don't need the `--debug-brk` of course.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through