Touch the pain points of debugging Node.js
If you have ever been lucky enough to write code for a Node.js project, then when I say that debugging it to find what went wrong is not the simplest thing, you know what I am talking about.
Unlike JavaScript in the browser or Java with a powerful IDE like IntelliJ, you cannot set breakpoints everywhere, refresh the page or restart the compiler, nor can you slowly review the code, check objects, evaluate functions, find mutations Or missing variables. You can’t do that, it’s too bad.
But Node.js can also be debugged, but it takes more effort. Let's seriously discuss these alternative methods, and I will show you the simplest debugging methods I have encountered in my development experience.
Optional methods for debugging Node.js
There are some ways to debug problematic Node.js programs. I listed these methods (including detailed links) below. If you are interested, you can go to understand.
Console.log() — If you have ever
written JavaScript code, this reliable backup program really needs no further explanation. It is built into Node.js and printed in the terminal just as it is built into JavaScript and printed in the browser console.
In the Java language, it is System.out.println(). In the Python language, it is print(). You understand what I mean. This is the easiest way to implement and the fastest way to "dirt" clean code with additional lines of information - but it (sometimes) can also help you find and fix errors.
Node.js documentation —-inspect — Node.js documentation writers themselves understand that debugging is not easy, so they made some convenient references to help people start debugging.
This is useful, but to be honest, unless you have written a program for a while, it is not the easiest to decipher. They quickly fell into the trap of UUIDs, WebSockets, and security risks, and I began to feel at a loss. I thought to myself: there must be a less complicated way to do this.
Chrome DevTools — Paul Irish wrote a blog post on debugging Node.js using Chrome developer tools in 2016 (and updated in 2018). It looks quite simple and is a big step forward for debugging.
After half an hour, I still did not successfully connect the
DevTools window to my simple Node program, and I am no longer so sure. Maybe I just can’t follow the instructions, but Chrome DevTools seems to make debugging more complicated than it should be.
JetBrains — JetBrains is one of my favorite software development companies and one of the developers of IntelliJ and WebStorm. Their tools have a wonderful ecosystem of plugins, and until recently, they were my preferred IDE.
With such a professional user base, there are many useful articles, such as this one, they debug Node, but similar to the Node documentation and Chrome DevTools options, this is not easy. You must create a debug configuration, attach running processes, and make a lot of configuration in the preferences before WebStorm is ready.
Visual Studio Code — This is my new gold standard for Node debugging. I never thought I would say that, but I fully invested in VS Code, and every new feature release made by the team made me love this IDE even more.
VS Code did all the other options that failed to
debug Node.js, which made it simple and fool-proof. If you want to make your debugging more advanced, this is certainly possible, but they break it down simple enough that anyone can get up and running quickly, regardless of your proficiency in IDE, Node, and programming. This is great.
Configure VS Code to debug Node.js
Okay, let's configure VS Code to debug Node. I assume that you have downloaded VS Code from here and start configuring it.
Open Preferences> Settings and enter node debug in the search box. There should be an extension called Node debug under the Extensions tab. Click the first box here: Debug> Node: Auto Attach, and then set the drop-down box option to on. You are almost done now. Yes, it is quite simple.
Now go to the project file and set some breakpoints where you want to see the code pause by clicking on the left sidebar of the file. Type node --inspect <FILE NAME> in the terminal. Now look, the magical thing happened...
VS Code ongoing code debugging
If you need a Node.js project to test it, you can download my repo here. It is used to test different forms of using Node to transfer large amounts of data, but it is very useful in this demo. If you want to learn more about streaming data nodes and performance optimization, you can click here and here.
When you hit the Enter key, the bottom of your VS Code terminal will turn orange, indicating that you are in debug mode, and your console will print some information similar to Debugger Attached.
When you see this happen, congratulations, you have Node.js running in debug mode!
At this point, you can see the breakpoints you set in the lower left corner of the screen (and you can switch the enabled state of these breakpoints through the check box), and you can debug like in a browser. At the top center of the IDE, there are small continue, step out, step in, and rerun buttons to complete the code step by step. VS Code even highlights the breakpoints and lines you have stopped in yellow, making it easier to track.
When you switch from one breakpoint to another, you can see that the program prints a bunch of console.log in the debug console at the bottom of VS Code, and the yellow highlight will also move with it.
As you can see, as the program runs, the more content the debug console outputs, the more breakpoints. During this process, I can use the tools in the upper left corner of VS Code to explore objects and functions locally , Just like I can explore the scope and objects in the browser. Not bad!
It's very simple, right?
to sum up
Node.js debugging does not need to be as troublesome as it used to be, nor does it need to include more than 500 console.log in the code base to find out the location of the bug.
Visual Studio Code's Debug> Node: Auto Attach setting makes this a thing of the past, which I am very grateful for.
In a few weeks, I will write some articles about end-to-end testing, use Puppeteer and headless Chrome, or use Nodemailer to reset the password in the MERN application, so please pay attention to me so as not to miss it.
