I've installed node-inspector just to find out that it doesn't support breakpoints :| What's the point in it at all, bearing in mind that on big part node code is asynchronous and you simply cannot follow it step by step?..
I'm definitely missing a point here...
Anyway to debug node code with breakpoints and everything?
yupp, I've successfully used node-inspector. If you want permanent breakpoints, simply insert debugger; in your code. See http://nodejs.org/api/debugger.html.
Making node wait until a debugger is attached, using node --inspect-brk script.js (previously node --debug-brk script.js), can also be very helpful.
(For Node 8 and later)
Node.js has a built-in debugger. Normally you can turn on the debugger in two ways:
Start your Node.js app or script with the --inspect or --inspect-brk switch. For example:
$ node.js --inspect index.js
(Note: --inspect-brk breaks before user code starts)
If for some reason you cannot start your Node.js app or script with the --inspect switch, you can still instruct the Node.js process to start listening for debugging messages by signalling it with SIGUSR1 (on Linux and OS X). For Node 8 and later it will activate the Inspector API, same as the --inspect switch
$ kill -sigusr1 23485
(Note: you need to replace 23485 with your own Node.js process ID)
With the debugger turned on, you can open the Google Chrome browser, and type in the address bar chrome://inspect
Then you should see an entry listed under "Remote Target". Go ahead and click "inspect".
Now you can set breakpoints and start debugging your code.
Reference:
https://nodejs.org/en/docs/guides/debugging-getting-started/
Related issue on stackoverflow:
Chrome Devtools Dedicated Node.js Inspector not stopping at breakpoints
To debug a Node.js application, one can use the debugging built-in method:
(1) Insert debugger; statement where you want to insert a break point
(2) Run the file with command $ node inspect <file name>
(3) Use a key for example, c to continue to next break point
You can even debug values associated to variables at that break point by typing repl. For more information, Please check the official guide.
Have you tried using nodemon library? it can be found here.
For development purposes you could start the app running nodemon. I have this script:
"dev": "nodemon --inspect src/index.js"
It will break any time a debugger statement is reached in the code. To open the console where you can see the server code, open the console in chrome and click on the nodejs icon:
It also helps you refreshing the server every time you save any file on the server.
Let me know if it works!
Just to elaborate a bit here:
Set a debugger wherever you want the breakpoints to be and then run your code with node debug script.js/index.js
When the debugger stops at you breakpoint, you will need to repl to inspect the variables.
Related
No matter what I do, I cannot get Rider to use Chrome for debugging. I've removed all other browsers listed and even set a "Custom path" to Chrome. I also have the required plugins installed and enabled; still, it starts up with:
Opening <URL> using the default OS app (=Edge)
It then starts logging errors like below:
Debugger listening on ws://...
Debugger attached.
Waiting for the debugger to disconnect...
About to exit with code: 0
Process terminated before summary could be written, possible error in async code no continuing!
Trying to exit with exit code 1
Process finished with exit code 0
The app consists of multiple SharePoint Framework (SPFx) React projects wrapped in netstandard2.0 class library projects. Each has a gulp file and I've created corresponding run/debug configurations similar to the below sample:
What do I need to do to get Rider to use Chrome?
In Gulp run configuration, you can't specify a browser to be used for debugging, neither you can debug the front-end app that runs in browser using this configuration. I suppose, it's your Gulp task that opens your system default browser once your app is started - the IDE has no control over this.
Anyway, to attach the debugger to the application that runs in browser, you need using JavaScript Debug run configuration with your server URL. In this configuration, you need to specify a browser to be used (the IDE will use Chrome there by default)
Also, I'd suggest removing --inspect option from Node options: in Gulp run configuration - it makes no sense here unless you are going to debug your Gulp task itself.
In all of my searching, I have not come across any trick, plug-in, or setting that would allow me to pre-populate a Watch Window for use during debugging.
The well-known steps to watch a variable in Visual Studio 2017 is to set a breakpoint (perhaps on the first instance of a variable being assigned a value), then, adding the variable to a Watch Window. On subsequent runs, that watched variable should remain in the Watch Window.
Is there a way to accomplish pre-populating the Watch Window before a debugging session? I have code that runs in a timed sequence. Taking the extended time during an execution break to pause and set up a watch causes the program to crash. Such timeout crashes while setting up variable watch objects makes for difficult interaction with the debugger. Pre-populating the watch list would help considerably.
I know that I could use a technique such as using Debug.Print(...) statements, which are printed to the Output Window during code execution. However, this doesn't allow me the control and visual feedback to my debugging efforts that comes from a Watch Window.
Watches can only be evaluated when you are paused in the debugger, say on a breakpoint. They can't be evaluated during normal execution. Your options to get around this limiation are:
Add Debug.Print(...) or something similar to your code that outputs a value.
Similar to #1 add a TracePoint which you'll find in the actions setting of a breakpoints setting (that's the gear icon when you hover over a breakpoint). When the TracePoints are hit they will then evaluate the expression that you specficied in the actions window and log it to the Output window. The advantage of TracePoints over adding your own logging is that you can turn it off and on without building your code. More info at: https://learn.microsoft.com/en-us/visualstudio/debugger/using-breakpoints?view=vs-2019#BKMK_Print_to_the_Output_window_with_tracepoints
Use the VS Enterprise only feature Snapshots which is part of IntelliTrace. Basically set your breakpoints but rather than stopping on them to look at the watch just continue. Each time you stop a snapshot of the process will be taken capturing the state of your application at that time. Then once you're finished use the Diagnostic Tools window to select each of the snasphots and activate them. For each snapshot you can use the debugger just as if you stopped the application. So you can use watches and inspect etc. Of course you can't step as the app has already ran but you can go to the next snapshot etc. More info at: https://learn.microsoft.com/en-us/visualstudio/debugger/view-snapshots-with-intellitrace?view=vs-2019 and https://devblogs.microsoft.com/visualstudio/step-back-while-debugging-with-intellitrace/
How Can Watch Variables be Configured in a Watch Window Before Running
a Debug Session in VS2017?
I'm afraid the answer is negative.For now,the Watch window can only be configured after the debug session start.It's like a runtime window only occurs during debugging.
So we can't pre-populate it before debug session for now. In other words, it's by design.
As alternative ways,you can follow Andy's detailed suggestions above.
And since your needs is meaningful in some specific debugging situation, you can also post your suggestion on development community like a user voice to add a new feature.
No matter if I choose "Attach to packager" configuration running packager with
react-native start
first or "Debug Android", breakpoints that I set in vs code are greyed out and are not get hit.
Here is information I am getting from Debug Console:
OS: win32 ia32 Adapter node: v7.9.0 ia32 vscode-chrome-debug-core:
3.23.0 Starting debugger app worker. Established a connection with the Proxy (Packager) to the React Native application Debugger worker
loaded runtime on port 10029 Running application "EugeneKrApp" with
appParams: {"rootTag":71}. DEV === true, development-level warning
are ON, performance optimizations are OFF index.bundle:19019 Warning:
componentWillMount is deprecated and will be removed in the next major
version. Use componentDidMount instead. As a temporary workaround, you
can rename to UNSAFE_componentWill
There is a bunch of warnings down the line like the last one about componentDidMount which I didn't include, they hardly influence debugging.
I had the same problem. It was due to the fact that 'Debug JS Remotely' was not enabled on the device/emulator.
Please check Tunvir Rahman Tusher answer and comments on this question.
Enter 'adb shell input keyevent 82' in the cmd/bash on your dev machine while the app is open on the device/emulator. A dialog box opens on the device/emulator like
Select 'Debug JS Remotely' and it will work out. You might need to restart the debugger.
My question is how can one put breakpoints in functional tests? Is it possible in Intern? I'm running the testcases locally on WebDriver, and having 'debugger;' breakpoints will ease my testcase development.
execute(function () { debugger; }) should run in browser and act on 'debugger;' in it, but it doesn't stop the execution...
I have this working. I start up a few terminals, start my selenium server jar in one, do node-inspector in another, and then fire up that url in chrome. I refresh the chrome window, then put node --debug-brk , and you will see the debugger catch, hit play - and it will go through to your debugger point. I also use the leaveRemoteOpen flag at the end of the command, which will leave the browser window open. my command looks like this:
node --debug-brk node_modules/intern/bin/intern-runner config=public/js/dojo/tt/tests/intern-config.js leaveRemoteOpen
also, in your config youll need this: excludeInstrumentation: /.*/
otherwise it munges your code.
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:
My breakpoints are never saved after I restart the server
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...
http://www.youtube.com/watch?v=AOnK3NVnxL8
or this one the scripts appear are already loaded in the first script
http://www.youtube.com/watch?v=HJOH0-g8f6E&feature=mfu_in_order&list=UL
Edit:
Nobody can answer this question? :s
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.
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.
Edit: However, according to the v8 DebuggerProtocol 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).
The new version (0.3.x) of node inspector saves breakpoints in browser's local storage and restores them automatically.
https://github.com/node-inspector/node-inspector/pull/116
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.
You can use node-codein for inspection. It won't do runtime breakpoints but it should ease the inspection process.
https://github.com/ketamynx/node-codein/
Also worth noting.. vscode has a great debugger for node.
https://code.visualstudio.com/
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).
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: https://youtu.be/rtZKUnks6jI