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.
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.
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?
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).
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).
You can also use the builtin `inspect` arg to node 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.
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...
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.
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.
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...
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.
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.
This looks really well done, great work Chrome Labs.
One thing I've missed is to be able to get a stack trace at moments of my choosing, in production mode.
Amazing, glad someone built something like this, really cool to be able to debug via Chrome DevTools.
Good work. It would be nice to be able to use the network and perormance tools offered by chrome.
lol, why, plenty of native tools out there.
YOU CAN GET A LOAN TODAY IF YOU CONTACT highraising@outlook.com
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!