I have a codebase where I have quite a number of
debugger;
statements. Sometimes I debug, and I actually just want to skip all of the debugger; statements and continue only to the manually set breakpoints that I have chosen for the debugging session, is there some setting by chance with Node.js to do that?
In other words, I would like to consider the debugger; statements to be long-term placeholders, but for certain debugging sessions I would like to ignore those long-term placeholders.
That can be done with the chrome devtools.
You can do:
node --inspect --debug-brk index.js
that will generate something like this:
chrome-devtools://devtools/remote/serve_file/#60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=localhost:9229/9c2e4f37-4c3a-4477-b8da-2399c5d9819e
Just copy and paste that on chrome.
There is an option to disable/enable all the break points, and chrome will remember all the breakpoints that you set previously.
Please check: --inspect for more info.
A trick I've used in the past is to just use babel to strip out debugger statements:
See:
https://www.npmjs.com/package/babel-plugin-remove-debugger
Quick and dirty way (its for debug so, its fine really) is to stick something like the following script in scripts/debugger.js
require.extensions['.js'] = function(module, filename) {
var content = fs.readFileSync(filename, 'utf8').replace(/debugger/g, [
'(function() {',
' if (__debugger) {',
' debugger;',
' }',
'})',
].join('\n'));
module._compile(content, filename);
};
then start node with node -r ./scripts/debugger
Using a global variable here so that it can be enabled/disabled from the debugger repl or chrome's repl if debugging with --inspect.
Technically require.extensions is deprecated, but it's not going to be removed and it works as intended here.
Related
I would like to have collapsible/ expandable objects in the terminal output in VS Code like on the browser console.
Here is an example:
In the debug terminal it works only if I toggle a breakpoint before the end of the program, but otherwise I get the error "No debugger available, can not send 'variables'".
So I'm thinking if the functionality is there, there must be a way to get it even without setting breakpoints every time. Right?
Use console.dir() instead of console.log().
Use this following example, to display all nested objects:
console.dir(yourStuff, { depth: null })
use
"outputCapture": "std"
in launch.json
I've been exploring the various ways to detect whether a node process has a debugger attached or not. I came across the straightforward looking process.debugPort, which is documented as:
process.debugPort
Added in: v0.7.2
<number>
The port used by the Node.js debugger when enabled.
What do the docs mean by "when enabled"? Or perhaps more to the point, when is the debugger not enabled? A simple test program shows that the process.debugPort always seems to be defined.
'use strict'
const debugPort = process.debugPort
console.log(`debugPort: ${debugPort}`)
Here is some command line output showing its invocation in node v10.22.1 – I tested node v15.3.0 and observed the same behavior.
➜ node --version
v10.22.1
➜ node nodeDebug.js
debugPort: 9229
➜ node --inspect=0.0.0.0:9999 nodeDebug.js
Debugger listening on ws://0.0.0.0:9999/db5cdb75-4745-4ea1-9a87-3f81c811c563
For help, see: https://nodejs.org/en/docs/inspector
debugPort: 9999
So even when invoking node without a --inspect flag, the debugPort is defined (and set to the default of 9229).
As an aside, the best method I've discovered for detecting whether node is in debugging mode or not is inspector.url() which
Return the URL of the active inspector, or undefined if there is none.
I'm not sure if this is bulletproof, but it covers my use case.
Even when you start without the explicit --inspect flag, it's always possible to enable the inspector on an ad hoc basis by sending the process a SIGUSR1 signal like so:
kill -SIGUSR1 $myNodePID
As such, it makes sense that the debugPort property is always set to something, as it's possible that it might be shortly used.
See towards top of here for passing sentence confirming this.
I'm just beginning to use Jest in my nodejs project. I have several test and all pass, but the last test I just coded is passing but is blocked in two places by Jest with code like this:
/* istanbul ignore next */
cov_19rdmie87d().s[43]++;
debugger;
/* istanbul ignore next */
cov_19rdmie87d().s[53]++;
this debugger;
I have to hit f5 to continue twice while running my tests. How can I remove these debugging statements?
Solution:
Remove debugger statements from your code and any kind of breakpoints from your inspect sources.
Some more Wiki on Debugging in JS
Debugger : If you place a debugger; line in your code, Chrome will automatically stop there when executing. You can even wrap it in conditionals, so it only runs when you need it.
Type debug(item.myFunc) in the console and the script will stop in debug mode when it gets a function call to item.myFunc
When you need to debug JavaScript, Chrome lets you pause when a DOM element changes. You can even monitor its attributes. In Chrome Inspector, right-click on the element and pick a break on setting to use.
For more information, check out this article by raygun on debugging in javascript.
Following this discussion I attempted to debug a mocha test script via the following:
mocha --inspect-brk ./tests/foo.test.js
This does indeed present an inspector URL that I can bind to in Chrome, but the "sources" are populated only with the source of mocha itself, not my code - is there something I need to change to get the inspector to bring up my code and not mocha's?
(I did see a similar question but I'm hoping for an answer that doesn't involve bringing in another dependency like node-inspector.)
Add debugger to one of your tests. When you resume in dev tools, execution will pause in your test code and you can browse your files.
it('should replace a template string', function(){
debugger
expect( Helper.templateString('{{a}}', {a:2}) ).to.equal( '2' )
})
You can also step over _mocha until it loads the files, which is around line 460 in v5.0.4, labeled requires:
// requires
requires.forEach(mod => {
require(mod);
});
After this you can browse your files and set break points. Dev tools will remember the break points for the next run.
One of the pleasures of frameworks like Rails is being able to interact with models on the command line. Being very new to node.js, I often find myself pasting chunks of app code into the REPL to play with objects. It's dirty.
Is there a magic bullet that more experienced node developers use to get access to their app specific stuff from within the node prompt? Would a solution be to package up the whole app, or parts of the app, into modules to be require()d? I'm still living in one-big-ol'-file land, so pulling everything out is, while inevitable, a little daunting.
Thanks in advance for any helpful hints you can offer!
One-big-ol'-file land is actually a good place to be in for what you want to do. Nodejs can also require it's REPL in the code itself, which will save you copy and pasting.
Here is a simple example from one of my projects. Near the top of your file do something similar to this:
function _cb() {
console.log(arguments)
}
var repl = require("repl");
var context = repl.start("$ ").context;
context.cb = _cb;
Now just add to the context throughout your code. The _cb is a dummy callback to play with function calls that require one (and see what they'll return).
Seems like the REPL API has changed quite a bit, this code works for me:
var replServer = repl.start({
prompt: "node > ",
input: process.stdin,
output: process.stdout,
useGlobal: true
});
replServer.on('exit', function() {
console.log("REPL DONE");
});
You can also take a look at this answer https://stackoverflow.com/a/27536499/1936097. This code will automatically load a REPL if the file is run directly from node AND add all your declared methods and variables to the context automatically.