
The Absolute Easiest Way to Debug Node.js – With VS Code - yannikyeo
https://itnext.io/the-absolute-easiest-way-to-debug-node-js-with-vscode-2e02ef5b1bad
======
paulirish
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](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.

~~~
emilsedgh
Read the article and came back to mention `ndb`. Cannot emphasis how easy it
is to debug with it.

If you're using node, do yourself a favor and `npx ndb` next time you wanna
debug something.

------
devnill
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](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/](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.

------
chrisparton1991
> 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.

~~~
np_tedious
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"?

~~~
mikewhy
Pretty sure all you need is source maps.

~~~
chrisparton1991
Yep, source maps do the trick.

~~~
np_tedious
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

------
Waterluvian
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.

------
brian_herman
[https://nodejs.org/api/debugger.html](https://nodejs.org/api/debugger.html)

------
keyle
This is just highly biased. It's just as easy with IntelliJ and doesn't
require any more fiddling around than this.

------
tluyben2
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.

------
mlevental
is there a way to debug promises in any of these debuggers? i.e. get a promise
to resolve when stopped at a breakpoint?

~~~
giobox
The “Smart Step” feature they added to the debugger a while back might be what
you are looking for.

> [https://code.visualstudio.com/updates/vApril#_smart-code-
> ste...](https://code.visualstudio.com/updates/vApril#_smart-code-stepping)

~~~
mlevental
no this isn't it. i'm saying i want to be able to "run" a promise while
stopped at breakpoint

