Code debugging can be roughly divided into Log and Breakpoint. The log is manually added to the code to obtain the log print process information to determine the problem. The advantage of this method is that it is easy to debug, and a skilled engineer can find business problems very quickly with good online logging. However, its disadvantages are also very obvious, the content of the acquisition is relatively simple, dynamic debugging needs to constantly add log printing code in the business.

Breakpoint debugging occurs. Breakpoint debugging is similar to the traditional Chinese medicine, we can obtain all the context of the program running to the point by making a breakpoint at the point to be observed, and observe the program running condition one by one by using single step debugging, and accurately determine the problem place. In addition, we can also use Chrome DevTool to debug online business at any time, can be said to be very convenient.

V8 Inspector

Chrome DevTool is well established for breakpoint debugging on the front end, and node.js (6.3+) comes with a similar debugger that implements the V8 debugger communication protocol inside Node. Add –inspect at startup to get the Chrome DevTools debug screen, and the rest of the debugging process is just like normal Chrome debugging.

Using –inspect debugging greatly facilitates Node.js development, so that server-side debugging also has the same experience as front-end debugging. In addition to opening DevTools directly for debugging, VSCode, WebStorm and other development tools also integrate it into the editor, but the internal principles are similar. No one is perfect, however, and Node Inspector has some drawbacks:

  • It needs to be added after the node command--inspectParameter for some third-party command startup cannot directly support debugging, for examplewebpack.ava.mocha.
  • Multi-process debugging is very troublesome, especially when the child process is frequently destroyed, the external manual monitoring process creation and manual process and debugging tool communication docking

Note: although VSCode uses the Inspector Protocol mode, the 1.22 version already automatically binds multi-process listener ports. For details, see the big VSCode debug Egg perfect edition.

ndb

Two weeks ago Chrome LABS opened source a new debugging tool, which is our hero today – NDB. It provides a much better debugging experience, and as the official repository says, it gives us the following features:

  1. The child process automatically detects and debugs access
  2. Support power off before module loading
  3. You can edit a file in the debugging tool and automatically update the file to a local file after saving the file
  4. By default, NDB is turned on for all referenced scripts outside the project folderThe black box modelAllows us to focus more on business code. Scripts outside the project folder include node.js’s built-in module files (e.g_stream_wrap.js.async_hooks.js.fs.js, etc.). Of course, you can disable this function by modifying the “Blackbox Anything Outside Working Dir” configuration in the Settings.

The installation

npm install -g ndb
Copy the code

First make sure your Node.js environment >= 8.0.0, and then use NPM install to easily complete the installation. Since NDB relies on Puppeteer and will download Chromium during Puppeteer installation, the download process may take some time, please be patient. Unsafe-perm =true –allow-root

use

Unlike node –inspect, NDB is very simple to use. Add the NDB command before any debug script you want to run, or even start the script directly with the NDB command. Here are some startup methods referenced from the repository example:

ndb node server.js

ndb npm run test

ndb mocha

ndb .
Copy the code

As with –inspect, the Chrome DevTools debug screen pops up after executing the command. In this special debug interface, you can:

  • Breakpoint debugging, asynchronous method step debugging
  • Console preexecution display (requires Node.js >= 10)
  • JS sample analysis
  • Memory analysis
  • Local terminal

ThinkJS debugging using NDB

The following uses Firekylin, a Node.js project developed based on ThinkJS, as an example to see how to use NDB for breakpoint debugging.

(The Nuggets currently do not support embedded video, so you need to jump to Tencent video to watch.) V.qq.com/x/page/t074…

As you can see, the basic debugging process is very simple and automatically ADAPTS to multi-process projects (8 processes started in the video), solving two problems with the previous use of –inspect. In addition, the console at the bottom, since it is a REPL environment, can get data about the current environment at the breakpoint in real time. For example, we can print process.memoryusage () to see the current memoryUsage.

In addition to breakpoint debugging, NDB also supports memory and performance analysis to help us analyze memory leaks and. For details, see Chrome DevTool Troubleshooting Memory Problems.

The problem of NDB

Still that sentence no one is perfect, NDB is still used down to feel a little uncomfortable. Mainly in the file update aspect, the current code is still written in the code editor, debugging needs to go to the NDB interface, frequent switching feeling a little uncomfortable. Hopefully VSCode will soon introduce NDB to replace existing debugging tools.

Some students will say why not edit files directly on NDB, after all, the support for file editing and saving is also a feature of NDB as a debugging tool. This is because in the multi-process environment, the debugging of each process is independent of each other. The modification of the file in one process can only be reflected in the modified process, not in all processes. It is different from our local operation file, so we need to pay attention to the use of the file. However, this is also easier to solve, debugging when only one process can be opened.

Afterword.

Node.js has more and more tools for breakpoint debugging. From the early Debug Protocol to V8 Inspector Protocol two years ago to NDB, we can see that technology is moving forward step by step. Of course, we have to thank the Chrome engineers for creating such a great tool. Of course, in addition to breakpoint step debugging, there is also a need for log debugging, the two can complement each other.

Finally, I will send you a picture to wish you a smooth week of BUG fixing

References:

  • Supercharge Your Debugging Experience for Node.js

  • DevTrends #32: NDB, What’s New in Chrome 68