I'm creating an own node but I'm stuck with it so I want to find the error with the node.js debugger. However, setting breakpoints in any node seems not to work at all.
Forgive me when this looks a bit hacky to you - I'm not very experienced with JS development. (yet)
I installed Node-RED via requiring it in the package.json in a empty folder and running npm install.
From there I go into node_modules/node-red and run it with node ./red.js. This is working so far. It also works to install another node by running npm install node-red-<pkg> in the ~/.node-red directory.
For debugging, I run node.js like this node --inspect-brk ./red.js. After that, I connect to the node.js debugging server with Chromium and I see it working so far. I can step through files of the Node-RED core.
The problem starts with inspecting a node which is installed in node_modules via npm link. I actually tried it the hard way by inserting a debugger; statement as the first line of a node constructor like this:
function StreamdeckInNode(n) {
debugger;
RED.nodes.createNode(this, n);
[...]
}
RED.nodes.registerType("streamdeck-in", StreamdeckInNode);
But the debugger doesn't stop at this point. I even tried to modify an existing and working node directly in the node_modules folder like above but still no breakpoint.
I have no idea what is going on here.
My environment (copied from the Node-RED output):
Node-RED version: v0.19.4
Node.js version: v8.11.3
Linux 4.19.6
I run node.js 8 on purpose (via NVM) because a certain node.js module doesn't work with 10+.
That is very weird. I alway use Chrome to debug all my contributions to Node-RED. Have had a lot of issues in the past, but not the one that you have...
Why are you only using --inspect-brk ? Because that is used to debug stuff at the start of your Node-RED application (like you can step through Node-RED). I only use that if I need to debug some flow startup behaviour. You should normally add --inspect=0.0.0.0:5858, so Chrome can connect to your NodeJS application to communicate via the debugger protocol.
It normally works fine, but it still stays experimental technologie! So if you upgrade to later NodeJs versions, you will see that the way of working changes unfortunately.
You will need to use both command arguments to let Node-RED halt at the first line AND make sure that from then on your debugger can communicate with NodeJs:
Will add some extra explanation below, for those who want to debug their code using Chrome...
Some remarks:
Note that you cannot debug code in function nodes! The code in a function node is one single piece of text, that is handed over to NodeJs to execute as one whole. I wrote some extra explanation in the past about it ...
Probably Visual Studio Code is much more powerful, but I debug using Chrome because it is simple and offers everything I need ...
When you search on the web, you will also come across a node-inspector module. In the beginning NodeJs had a dedicated debug protocol, so you needed that browser plugin to connect your browser debugger to NodeJs. However now NodeJs supports a standard debug protocol, so browser like Chrome can directly communicate with NodeJs without plugins. So we won't use that technology in this discussion ...
I use Chrome both to debug:
The client-side of my node (which runs in my browser like the Dashboard or the Flow editor), i.e. the Javascript used for my node's config screen. For example stuff from the oneditprepare function.
The server-side of my node (which runs in my flow on my Raspberry), i.e. the code that is e.g. triggered when a new input message arrives.
As mentioned before the technology (to debug server-side NodeJs from Chrome) is experimental, so it changes from time to time how it has to be used:
In older NodeJs versions you had to startup Node-RED (on a Raspberry for example) like this:
Then in the command line an URL will be displayed automatically:
Chrome-devtools:// ...
You have to copy that URL and paste in your Chrome browser. And then the developer tools opens and you can start debugging. Additionally you can add extra--debug-brk in your command (after --inspect), so it would stop immediately at the first line of the Node-RED application. This is e.g. necessary when you want to debug code from Node-RED startup, or the startup code of your node. E.g. this part of your Node:
function MyCustomNode(config) {
RED.nodes.createNode(this, config);
// This startup code needs to be debugged (e.g. after deploy)
}
This way of working gives you a change to put your breakpoints before the flow is started...
Starting from starting from NodeJs version 7.5.0, you need to specify extra in your command which remote ip address is allowed to debug (see this security issue in NodeJs)):
So that is the IP address of the computer where you are running Chrome. I 'think' you could use 0.0.0.0 to allow all IP addresses ...
Starting from NodeJs version 8.?, the command displays a ws://... address instead of chrome-devtools://... address. To open such an URL with Chrome you have to follow these steps:
Navigate to chrome://inspect
Once you have to specify the IP address of your server (in my case the Raspberry running my Node-RED) via the 'Configure' button:
You can specify here the IP addresses of ALL your Node-RED servers, that you ever want to debug...
Once you start one of those servers in debug mode (i.e. with the --inspect ... command), those entries will become clickable in this screen:
If you don't see the link appearing, refresh this page.
When you click on the 'inspect' link, the developer console will open and you can start debugging...
I'm only using the latest mechanism, so I cannot test the others anymore for you (in case of troubles)!
Thank you very much for your in-depth instructions. I decided to grab a Raspberry PI with Raspbian as a clean environment (This was my long term target platform anyway) to start over and deployed my nodes on it while keeping your instructions in mind. It is working now! Seems like I really messed up my local environment somehow.
Not sure if this works for chrome debugging but in vscode, I include --preserve-symlinks in the debug settings file.
Not able to paste a copy of my launch JSON right now but if you do a quick google search on vscode launch node -preserve-symlinks you'll find the info.
Hope that helps you or others debugging sym linked own nodes.
