
Ndb – An improved debugging experience for Node.js - ginkoid
https://github.com/GoogleChromeLabs/ndb
======
skrebbel
Because competition is good, I want to quickly name-drop VS Code here, which
has had _excellent_ integrated node debugging for quite a while now. It
integrates seamlessly with the entire tool ecosystem (eg I use ts-node-dev for
autoreloading + typescript support, and the VS Code debugger Just Works). And
because it's inside the editor, ndb features like the ability to put
breakpoints in a file before it is required are irrelevant. It's all at your
fingertips, just put a breakpoint right where you're coding, hit F5 to attach
the debugger to your devserver and step through the code.

It's a pretty amazing experience, finally putting Node at the same level as,
say, PHP with XDebug and NetBeans in 2006. Of course reloads are still slower,
but that's all. JS is getting there!

~~~
alangpierce
WebStorm (and everything in the IntelliJ family) also has a really nice
debugging experience. Very similar benefits to what you described: it mostly
Just Works, at least for my use cases, and you just add breakpoints to where
you're already coding rather than needing to do things in a separate window.

That said, with both VSCode and WebStorm, I've seen finicky issues from time
to time, like source maps not working right or trouble getting it to work with
non-trivial test suites. For example, my company's test suite uses a wrapper
CLI that pre-loads certain files and sets environment variables in a specific
way, and I need to replicate that configuration manually in order to run tests
from WebStorm. I'm certainly excited to see ndb as a "baseline" great
experience that everyone can use, regardless of editor.

~~~
dzhiurgis
Sadly I find IntelliJ to be the worst editor I've ever seen. Slow, weird
shortcuts, graphics problems, focus stealing. The downsides are so bad that it
almost negates it's benefits.

Unfortunately, for Salesforce development the alternative is VSCode with
subpar plugin (and tons of features blatantly stolen from independent IJ
plugin developer)...

~~~
partycoder
Performance can be improved by disabling plugins you don't use, disabling
features like code folding, etc. and finally by excluding non-essential files
from indexing.

I don't know about the graphics problems but you can disable focus stealing in
your window manager. During the first time setup you are given the option of
using other keys. For a vim-like experience you can use IdeaVim.

For node, IntelliJ gives you: code completion across files, debugging (local,
remote, including Docker), testing (e.g.: automatically recognizes test cases
and creates a run configuration from them), code coverage, type inference from
JSDoc documentation or flow, linting, version control integration with
excellent blame integration, etc.

~~~
dzhiurgis
Wow that was a lot of plug-ins to disable. Took me a while. It's shocking how
they left enabled by default.

> disable focus stealing in your window manager

Can you expand more on this. Two issues I have is:

\- Launching IntelliJ and another app simultaneously would pop IJ on top. Very
indicative of how Windows platform works. Basically not an issue as I launch
it like once a month.

\- Saving/building something would switch focus to Messages panel. Clicking on
item in project view opens a file, but typing still happens on project view
panel...

~~~
alangpierce
I've actually run into different focus issues, stuff involving WebStorm
multiple project windows on Mac and the wrong one getting focus.

For focus within the editor, I've been pretty happy, but it does take a little
learning to get a feel for the keyboard shortcuts. Quick rundown on focus, at
least on Mac (other platforms/keymaps are mostly similar, I think):

• Cmd+1, Cmd+2, Cmd+3 etc focus and toggle the different panels.

• Wherever you are, Escape gets you back to the code. Shift+Escape closes the
focused panel and moves back to the code.

• Option+Tab switches between code panes.

• Whenever you open code from any panel, Enter will open the code and leave
focus on the panel, and Cmd+Down will open the code and move focus to the
code.

I find it easy enough to switch focus that even if an action ends up in a
focus state I don't expect, it's just a little muscle memory to move focus to
what I want.

------
sarreph
It somewhat blew my mind the other day that you can add an '\--inspect' flag
to a locally-run node instance and inspect it via Chrome (chrome://inspect).

After building a server for many months now, and relying on far too many
_console.log()_ s, this trick has enlightened me to the point where I feel as
though I was a fool for not finding it out before!

Ndb looks like a promising improvement over this functionality and I'm excited
to check it out.

~~~
shriek
Recently I discovered that you can flip to debug mode even on already running
process without debug mode by doing 'process._debugProcess(<pid_of_process>)'
on any other node process. This has made my life incredibly simpler by not
having to remember whether I had run my app in debug mode with '\--inspect'
flag.

~~~
thedufer
IIRC, `process._debugProcess` just sends a SIGUSR1 to the provided PID.

------
felixrieseberg
This looks really, really impressive. I'd love to connect this to Electron
apps, too.

As someone who wants Windows users to have a decent time using and developing
with Node.js, it warms my heart to see developers of modules to at least
consider them. As the maintainer of `windows-build-tools`, it makes me so
happy that more and more modules are including it as an installation
instruction.

~~~
skrebbel
Yo, it's efforts like yours that make Node one of the best cross platform dev
environments out there. Thanks!

------
dfee
As a secondary language, I find the repl and debugging pieces far lacking for
Node.js. To be fair, I just use Node.js for developing SPA using frameworks
like VueJS and React.

Ndb looks like a step in a good direction. However, I don’t understand if
you’re really expected to have a Chrome browser open when you’re already in
the context of editing code.

That might sound strange, but my preferred setup is using tmux and splitting
vim on the left and a couple terminal panes on the right (at about 80 chars).
Is terminal debugging possible with ndb? Am I thinking about this wrong?

~~~
closed
Agreed. I've been scratching my head over whether the rough debugging has been
a lack of tools available, or me not knowing where to look. (From other
comments, it looks like there are a few promising tools out there)

------
namanyayg
It's interesting to see Google build open-source tooling in this direction;
catering to the developers ensures that Chrome keeps enjoying a large market
share.

Google has made serious efforts here and as a web developer, Chrome's tools
are by far some of the best I've seen (with an honorable mention to FX's tools
for Flexbox & Grid).

~~~
pjmlp
Including "Works best on Chrome™".

~~~
skybrian
Yes, this sometimes happens, but you shouldn't let that overshadow the Chrome
team's commitment to web standards and open source.

~~~
mort96
You're right, you shouldn't let that overshadow the Chrome team's commitment
to open source. You should maybe let the fact that Chrome is closed source
overshadow the Chrome team's commitment to open source.

~~~
skybrian
Yes, it's true that Chrome has closed-source components. Meanwhile, Chromium
is still available. Node and Electron wouldn't exist without having Google's
work to start off with, as a base for the work of many others. (Though of
course Google was building on the early work at Netscape, and some features of
web standards were invented at Microsoft, despite IE not being open source at
all).

This way of building on the work of other people (hopefully giving due credit)
is how open source is supposed to work. It doesn't mean Google can or should
do everything for the community; if we don't like the direction Google is
going we need to do some of the work ourselves.

~~~
pjmlp
I actually given that I have to deal with apps that should have been web
based, but are not, 'cause dev convenience.

And having to untangle npm based builds to what used to be a simple set of
scripts and HTML includes, because many JavaScript libraries assume a node
based deployment and nothing else.

With those outcomes I do not consider it a good result.

------
rvanmil
Does this let me inspect network activity like I can with web apps? I
currently use Charles Proxy for this because I haven’t found a better way to
do this (also for Electron apps and network activity on the main process).

~~~
mlevental
you know that's something i think i've always wanted but never realized until
you just brought it up - something like the network tab from chrome dev tools
would be super useful in any ide that caters to a language that people write
web apps in (node/python/etc.).

to answer your question:

from the screenshot it looks like the answer is no

[https://user-
images.githubusercontent.com/39191/43023843-14a...](https://user-
images.githubusercontent.com/39191/43023843-14a085a6-8c21-11e8-85b7-b9fd3405938a.png)

------
morenoh149
You can also use the builtin `inspect` arg to node
[https://nodejs.org/dist/latest-v10.x/docs/api/debugger.html](https://nodejs.org/dist/latest-v10.x/docs/api/debugger.html)

For those comfortable with python's pdb, this provides a similar interface for
debugging node applications. I was hoping this was an improvement on that as I
prefer to stay within the commandline.

------
bvm
This looks fantastic! My project has a build process that transpiles the
source directory using Babel to a build dir, and then runs from that. Is it
possible to use a sourcemap to debug based on the pre-transpiled source?

edit: i've built the sourcemaps, and like devtools, it is recognising them,
but even though the source directory is in the working tree, it doesn't pick
them up...

~~~
ne0free
try mapping your workspace in Filesystembtab under sources

~~~
mattslight
I have the same issue. I transpile code from ./src to ./dist

In NDB I am on sources tab and I see dist folder highlighted (src also appears
in the tree).

How does one "map the workspace under sources" (I tried right clicking - and I
don't see a menu)

TIA

------
timmyla
This might be a dumb question, but does anyone know how to "blackbox" the
files that are not in working dir while debugging Node with VSC? I have a
backend server that handle requests and often have to set a debugger, but find
myself having to click through multiple "events_hooks.js" type of functions.

~~~
gwicksted
[https://github.com/Microsoft/vscode/issues/16208](https://github.com/Microsoft/vscode/issues/16208)

Try that (I haven’t yet) - let me know if it works out for you! I was just
wanting something similar the other day and this is on my to-try list

------
kostarelo
I never really understood how people are using a debugger these days,
especially in a heavy I/O bound app such as Node.js services. I mean, once it
hits the DB, there is no way of “stepping back”.

I used to use debuggers back when I was developing desktop apps on Java using
Eclipse. It made sense to use a debugger back then cause the whole app was
running locally inside the same execution stack, including its state and its
business logic. You were in control of how the data flow and in which
direction.

But nowadays, you have an API request with a short lifecycle which 90%
includes handing the execution to other processes through the network. What is
the purpose of using a debugger? You can just write an automated test that
would automatically run on every file change.

~~~
IggleSniggle
There's some crazy stuff floating around...think db like functionality written
into node apps....

------
proph3t
We do something like this already but because we have three processes that
interact we scripted puppeteer to hook into all three in different tabs and
automatically refresh the tabs when the processes restart.

It also clicks into the console to start and turns off screencasting, etc.

Here's a gist of the main part:
[https://gist.github.com/natew/66515fb49d895315e139059302cd47...](https://gist.github.com/natew/66515fb49d895315e139059302cd471b)

------
faureka
We are dependent a lot on childprocesses (I know it sucks, but it's a legacy
system) in our app. This is just amazing letting the debugger attach to the
child process. Finally no more console logs to figure what's wrong.

------
craftoman
It is indeed similar to Webstorm but it's free. For all the users out there
who need an enterprise debugging experience for free without any annual fees,
Ndb does the job really great imho.

~~~
pjmlp
That is why we cannot have nice things.

Anyone that wants to invest their career doing tooling needs to target
enterprise customers.

~~~
Techonomicon
We can't have nice things because non-enterprise historically (on the whole)
will spend --zero-- dollars for software they use.

------
orta
This looks really well done, great work Chrome Labs.

------
amelius
One thing I've missed is to be able to get a stack trace at moments of my
choosing, in production mode.

------
jpincheira
Amazing, glad someone built something like this, really cool to be able to
debug via Chrome DevTools.

~~~
kabes
Debugging in chrome devtools was already possible by default. This just adds
some features.

~~~
alangpierce
I would say it also lowers the barrier to entry.

Previously, you had to add a `debugger;`, visit "chrome://inspect/" in the
browser, click "Open dedicated DevTools for Node", and leave it open while
running node (mocha tests, in my team's case) from the CLI with --inspect.
None of that is _hard_ , and certainly it's much easier than previous
alternatives, but it's still enough that it needs instructions. I got it set
up for my team and made our test script print out those instructions, but even
so, I think most developers viewed it as more of an "advanced" mode for when a
test issue is really hard to track down.

With this new way, you run the test in debug mode and it pops up a window with
everything set up already, no need for instructions. I'm hoping it'll make
debugging easy/welcoming enough that more people will use a debugger as their
default way to work on code.

~~~
city41
\--inspect-brk will start the node process then immediately break. It looks
like ndb supports inspect-brk too.

~~~
alangpierce
At least in my situation, with no additional configuration, --inspect-brk
works, but when it's paused at the start, I can't navigate to any of my files
to set breakpoints, so the most straightforward way to set a breakpoint is a
`debugger;` statement in the code. I guess that's one of the things that works
better in ndb: "You can place breakpoints before the modules are required".

~~~
city41
It looks like ndb solves that problem: "You can place breakpoints before the
modules are required."

------
pastelsky
Good work. It would be nice to be able to use the network and perormance tools
offered by chrome.

