ROS distributes robot concerns across dozens of nodes on a robot, possibly thousands of nodes in a fleet. Many of these are Python. It's been a joy using vscode to connect to a live running robot and the master server and remote debug a bunch of nodes at the same time.
While VS Code is a great IDE, a lot of this article is simply untrue. Node has had an interactive debugger (and corresponding API) for years.
Prior to --inspect, --debugger gave developers the abilities to step through code and to jump into a REPL to examine and manipulate the application state. Beyond this, there were tools like node inspector(https://github.com/node-inspector/node-inspector) which provided a chrome inspector-like tool.
On top of that, these tools adhere to the chrome debugger API (https://chromedevtools.github.io/devtools-protocol/) which provides the ability to dump comprehensive data like the memory graph for those wishing to make profiling tools.
> Unlike JavaScript in the browser, or Java with a powerful IDE like IntelliJ, you can’t just set breakpoints everywhere
I'm using IntelliJ to set breakpoints everywhere in a Node application at this very moment. It's super easy to set up, you just create a Node.js run configuration and hit the debug button.
How does this work with transpilation? Say I have typescript or a just different js than the end build, how does the debugger know which line to put the breakpoint on?
Does the run config need to be something more structured than "run this gulp command"?
late response, but i just got stop debugging for a typescript/node app set up in webstorm. far easier than i (and this article) had built it up to be. the sourcemap stuff was actually already taken care of, it was the addition of `$NODE_DEBUG_OPTION` to the `ts-node-dev` command that did the trick
You can do this in VS Code as well. You create a launch.json file, and you can debug. A basic launch.json file is like 3 lines long, and VS Code makes it for you. There's no need for an extension. Maybe the author wasn't aware of that.
The author linked to a post of mine for debugging Node with Chrome DevTools I agree that it's a little frustrating. But a few months ago, the `ndb` project launched with a phenomenally better user experience for this: https://github.com/GoogleChromeLabs/ndb
It has child processes support, easy Ctrl-R hotkey to restart your node, breakpoints can be placed anywhere, and nice default blackboxing of node internals. Worth a spin.
How do I make my code not trigger the debugger breakpoint whenever a promise fails? I get that the fail isn’t being handled but isn’t there to make a default handler in that case?
Honest question: is there anyone here who uses Node that didn't figure this out themselves with VS Code or other editors in a few minutes? And then a lot of the info is (as already mentioned here as well) not true; this is nothing new nor special.
19 comments
[ 2.9 ms ] story [ 48.9 ms ] threadPrior to --inspect, --debugger gave developers the abilities to step through code and to jump into a REPL to examine and manipulate the application state. Beyond this, there were tools like node inspector(https://github.com/node-inspector/node-inspector) which provided a chrome inspector-like tool.
On top of that, these tools adhere to the chrome debugger API (https://chromedevtools.github.io/devtools-protocol/) which provides the ability to dump comprehensive data like the memory graph for those wishing to make profiling tools.
I'm using IntelliJ to set breakpoints everywhere in a Node application at this very moment. It's super easy to set up, you just create a Node.js run configuration and hit the debug button.
Does the run config need to be something more structured than "run this gulp command"?
It has child processes support, easy Ctrl-R hotkey to restart your node, breakpoints can be placed anywhere, and nice default blackboxing of node internals. Worth a spin.
If you're using node, do yourself a favor and `npx ndb` next time you wanna debug something.
> https://code.visualstudio.com/updates/vApril#_smart-code-ste...