Summary of essential breakpoint debugging techniques for JavaScript (recommended)

Why use a debugger?

This article will introduce how to use breakpoints for JavaScript debugging. Before reading this article, you need to ask a question: Why use breakpoints for debugging?
We need to understand the necessity of using breakpoints, otherwise all the breakpoint debugging methods introduced below will be nonsense. console.log is the most commonly used debugging method in front-end development. It solves some problems simply and directly. But when you encounter very complex problems, console.log becomes inadequate. for example:

• If you have ever practiced LeetCode, you will have a deep understanding of a logically complex algorithm. When a test case of the algorithm reports an error, it is sometimes difficult to find the problematic method by visual inspection alone.
• A bug with very cumbersome steps to reproduce.
  It took me 10 minutes to reproduce the problem, but I only traced it to a certain line of code. I needed to add log a second time to continue looking for the problem. View log -> Add log -> View log... Repeat this process several times, and you won’t be able to move all the remaining bricks today.
• A piece of code with a lengthy running process
• A piece of code with no comments and random names
• For server-side code, students who have experience in nodejs server-side development may have experienced jumping back and forth between postman <-> ide. If you only rely on logs, it is difficult for the console to view the full picture of a huge and complex object. If an interface also involves database additions and deletions and third-party dependencies, then restoring the consequences of the last request is also a painful task.

In these cases, breakpoint debugging is very valuable, reducing the debugging time complexity from O(n) to O(1), making brick-moving more enjoyable.

Here is the article’s outline:

• Basic usage of Chrome debugger
• VS Code debugging SPA application
• Chrome debugging Nodejs
• VS Code debugging Nodejs

Basic usage of Chrome debugger

The simplest breakpoint debugging is to add a debugger statement in the code and then refresh the page in the browser. The browser will then stop executing at the debugger statement.

To facilitate understanding, let's introduce a simple example. Create index.html and index.js in a folder, and then import index.js into index.html. The content of index.js is as follows:

// International practice, hello world.
const greet = () => {
  const greeting = "hello debugger";
  // The browser will pause the debugger when it executes here
  console.log(greeting);
};

greet();

console.log("js evaluation done");

Execute the command:

npm i -g serve
serve .

Then visit http://localhost:5000 and open the developer tools.

At this time, our hello world breakpoint is set, like this:

The picture is divided into four areas. The blue area is used for file selection. The Page column refers to the JS file in the current page. Filesystem will display the files in our system. Usually we use Page.

Pink is the line number and content of the code. You can click on the line number of the code to add a new breakpoint, and click again to cancel.

The yellow area is used to control the execution of the code. You only need to master the meaning of the first four buttons to cope with most scenarios. Button 1 allows the code to continue executing (resume). If the next breakpoint is encountered, the execution will be interrupted again. Button 2 allows the browser to execute the current line (line 3 in the figure) and then interrupt the code at the next line. Button 3 enters the current function and views the specific content of the function. Assuming we are currently at greet() on line 7, clicking button 3 will enter the greet method (that is, line 2). If you don't want to look at the greet method anymore, click button 4 to exit this method and return to line 8.

The green area allows you to view the contents of variables and the current call stack.

Debugger is the simplest and most brutal way to set breakpoints, but it requires modifying our code. It should be noted that these statements must be deleted before going online. It can also be automatically removed by configuring webpack. But it is still a bit inconvenient, so let's see how to simplify the way of breaking points through vscode.

VS Code debugging SPA application

First, we use Vite to create a Vue application for demonstration (the React steps are similar).

# Create vut-ts application npm init vite
cd hello-vite
npm install
# Call VS Code cli to open the project, or open it manually in VS Code.
code .
npm run dev

Then create a new file .vscode/launch.json in VS Code and fill in these contents:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "pwa-chrome",
      "request": "launch",
      "name": "Launch Vue project",
      // Fill in the project's access address "url": "http://localhost:3000",
      "webRoot": "${workspaceFolder}"
    },
  ]
}

Then use cmd+q to exit your running Chrome (this step is very important and cannot be skipped), and press f5 to start the debugging function of VS Code. VS Code will help you launch a Chrome window and access the URL in the above configuration. At this time, our breakpoints will take effect, and we can control the execution of the code step by step to find the source of the bug.

Here is a practical tip, which is to check Uncaught Exceptions in BREAKPOINTS, so that the execution will be automatically interrupted where the code reports an error. When we encounter an error, this method can save time locating the problem code.

In addition, we can find that when the VS Code breakpoint takes effect, Chrome Devtools will also display the breakpoint synchronously.

In VS Code, there are two debugging modes: launch and attach. Since it is the JS engine in Chrome that actually executes the code, the control of whether to interrupt the code is in the hands of Chrome. So why can VS Code's breakpoints control code interruption? This is because VS Code sends instructions to Chrome through the devtools-protocol, telling Chrome which line of code to pause execution on. The process of sending instructions is called attach. The launch process includes attach, that is, first launch (start) the browser, and then attach (attach) the breakpoint information. So attach mode is a subset of launch mode.

It sounds like launch mode will be more convenient, saving us the process of manually launching the browser. But there is a problem. What happens if multiple front-end projects are developed at the same time? If you start a debugging process for each project, multiple browsers will be opened, and switching between multiple browsers will become very troublesome. We can use the attach mode to solve this problem.

First we launch Chrome using the command line. The reason for using the command line is that we need to pass parameters to Chrome's startup.

# Before running this command, you need to exit the running Chrome by pressing cmd+q
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
# If you see this output, it means the parameter transfer is successful.
DevTools listening on ws://127.0.0.1:9222/devtools/browser/856a3533-ca5c-474f-a0cf-88b7ae94c75b

VS Code and Chrome communicate via websocket, and --remote-debugging-port specifies the port used by websocket. Then we modify the launch.json file to look like this:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "pwa-chrome",
      "request": "attach",
      "name": "Vue Application",
      // URL for project access
      "url": "http://localhost:3000",
      // The websocket port must be consistent with the --remote-debugging-port parameter.
      "port": 9222,
      "webRoot": "${workspaceFolder}"
    },
  ]
}

Note that before starting VS Code debugging, you need to open the http://localhost:3000 page in Chrome. Then we set a breakpoint in VS Code, refresh the browser, and the code successfully stops at the breakpoint. The second and nth projects can use the same configuration, the difference is that the url field needs to be modified according to the project configuration.

Chrome debugging Nodejs

The above article talked about how to debug the page. Next, let’s talk about how to debug the nodejs application. Let's start with the easiest example and create a hello world:

// debug.js file const greeting = 'hello nodejs debugger'
debugger
console.log(greeting)

Then run this file

node --inspect-brk debug.js
Debugger listening on ws://127.0.0.1:9229/b9a6d6bf-baaa-4ad5-8cc6-01eb69e99f0a
For help, see: https://nodejs.org/en/docs/inspector

--inspect-brk means setting a breakpoint on the first line of the file while running the js file. Then open Chrome and go to Devtools. Click the button in the red box, a nodejs-specific debugging window will open, and the code will be interrupted at the first line.

Nodejs debug window:

The essence of this method is that Chrome Devtool sends instructions to the nodejs process according to the debugging protocol of the v8 engine to control the running of the code. It can be found that in web page debugging, Chrome is the party that receives instructions, while in nodejs debugging, Chrome turns into the party that sends instructions. The so-called gorgeous transformation from the miserable Party B to Party A.

The default websocket port of node is 9229. If necessary (for example, the port is occupied), we can change this port in some way.

node --inspect=9228 debug.js
Debugger listening on ws://127.0.0.1:9228/30f21d45-9806-47b8-8a0b-5fb97cf8bb87
For help, see: https://nodejs.org/en/docs/inspector

When we open Devtool, Chrome checks port 9229 by default, but when we change the port number, we need to manually specify the address that Chrome checks. Click the Configure button in the image below, enter 127.0.0.1:9228, and click Done. At this time, the node process just started will appear in the Remote Target. Click inspect to start debugging.

Debugging Nodejs with VS Code

So far, we have achieved the goal of debugging node, but it is still a bit cumbersome and not automated enough. We can use VS Code to start debugging with one click.

Open the project in VS Code and enter the following in launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "pwa-node",
      "request": "launch",
      "name": "Launch Program",
      "skipFiles": [
        "<node_internals>/**"
      ],
      // ${file} means that when we start debugging, the debugged program is the current focus file.
      "program": "${file}"
    }
  ]
}

At this time, switch to the index.js file and press F5 to start the debugger. When it runs to the second line of debugger statement, the execution will be automatically paused. You can also click on the left side of the code line number to set a breakpoint.

If we want to debug TypeScript, we just need to rename index.js to index.ts and then modify launch.json.

{
  "type": "pwa-node",
  "request": "launch",
  "name": "Launch Program",
  "skipFiles": [
    "<node_internals>/**"
  ],
  "program": "${file}",
  // Before debugging, you need to compile TypeScript into JS.
  "preLaunchTask": "tsc: build - tsconfig.json",
  
  // Here we are telling VS Code where the compiled code files are output.
  // You need to specify outDir as dist in tsconfig.json.
  "outFiles": [
    "${workspaceFolder}/dist/**/*.js"
  ]
}

There are two points to note for TS debugging

1. The outFile path in launch.json needs to be consistent with outDir in tsconfig.json.
2. Specify sourceMap as true in tsconfig.json.

Conditional Breakpoint

In some cases, we don't want every breakpoint to take effect, but to interrupt code execution when the breakpoint line is executed and a certain condition is met. This is a conditional breakpoint.

for (let i = 0; i < 10; i++) {
  console.log("i", i);
}

For example, in the code above, if we set a breakpoint on the second line of console.log, then this breakpoint will be interrupted ten times in total. This is often what we don't want to see. Maybe we only need one of the cycles instead of all of them. At this time you can right-click and select Add Conditional Breakpoint.

At this time, an input box will appear, and we enter i === 5 in it.

When debugging is started at this time, i will be skipped to 0 - 4, and the code execution will be interrupted directly when i is 5. After resuming the code execution, the cases where i is 6 - 9 will be skipped.

Conditional Breakpoint is extremely useful when debugging code with a large number of loops and if-else statements, especially when the overall logic of a certain place is as expected, and only some special cases have output errors. Using conditional breakpoints, you can skip these normal situations and only interrupt execution when some special cases occur, so that we can check whether the calculations of various variables are normal.

Summarize

Debugging is a very important skill in daily work, because in addition to developing new features, a large part of the daily work is spent adjusting old code and dealing with logical errors under special conditions. Proficiency in debugging can greatly improve the happiness of brick-moving work. A complex bug that can get you stuck for several hours can easily cause you to feel psychologically frustrated. But it doesn’t mean that breakpoint debugging is a silver bullet applicable in all situations. Simple logic can still be console.log happily. This article introduces how to use Chrome Devtools and VS Code breakpoint debugging. Overall, VS Code is more recommended. launch.json only needs to be configured once, and you can start debugging with one click of F5 afterwards. In addition, the configurations of various launch.json files mentioned in the article can be generated with one click using the tools provided by VS Code. As long as you open launch.json, the Add Configuration button will appear in the lower right corner of the editor. Click it to select the debug configuration you need to add.

This concludes this article on essential breakpoint debugging techniques for JavaScript. For more content on JavaScript breakpoint debugging techniques, please search previous articles on 123WORDPRESS.COM or continue browsing the following related articles. I hope you will support 123WORDPRESS.COM in the future!