How Do You Debug in DevTools?

The tools in the sources panel are the core of it. A breakpoint pauses execution and lets you inspect the state at that line. You set one by clicking the line number in the source view, and you can drag a breakpoint to a different line without setting it again.

Conditional breakpoints are the feature that makes the tool practical for large code bases. Instead of pausing on every iteration, you give the breakpoint a condition, and it only pauses when the condition is true. For a bug that only happens on one item in a long list, that is the difference between a two minute fix and an hour of clicking.

The step controls are the other half. Step over runs the next line without entering a function, step into enters the function that is about to run, and step out leaves the current function. Step over is the one you use most, because it is the one that keeps you at the level of code you care about.

Two more that matter. The watch panel evaluates expressions in the context of the paused frame, so you can inspect a variable or call a function on the current state without changing the code. And the call stack pane shows how you got to where you are, which is how you find the code that is calling something you thought nobody called.

For JavaScript specifically, the debugger statement pauses execution and opens the sources panel if it is not already open. Putting it in the source lets you reload and have the debugger waiting at exactly that line, which beats hunting for the right file by hand.

Not every bug can be reproduced in a browser, and a server or a test environment needs its own toolkit. These techniques work anywhere Node runs.

// A tiny logger that shows values, types and where they came from.
const inspect = (label, value) => {
  console.log(`${label}:`, value, "|", typeof value);
};

const user = { name: "Ada", age: 36 };
inspect("user", user);
inspect("user.name", user.name);
inspect("missing", user.nickname);

// A breakpoint you can drop in without a debugger: a conditional trace.
const trace = (label, condition) => {
  if (condition) console.log("hit:", label);
};

for (let i = 0; i < 3; i++) {
  trace(&#96;loop ${i}&#96;, i === 1);
}

// A table of objects, which is far easier to read than a list of logs.
console.table([
  { id: 1, name: "Ada" },
  { id: 2, name: "Bob" },
]);

// Node can also open a real debugger on the file.
console.log("Run with: node --inspect-brk app.js");

The pattern of pairing a label with the value and its type is worth building into a helper. When the value is not what you expected, the type is usually the clue, and printing both saves a second round trip.

The conditional trace is a poor person's breakpoint. It costs a tiny amount of performance and it only fires on the condition you care about, which makes it a good fit for a tight loop where a debugger would be too slow to step through.

For anything more serious, Node has a full inspector protocol. Running the process with the inspect flag gives you the same breakpoints, watches and step controls as the browser, and you can attach an editor to it. That is the right tool when the bug only reproduces on real data in a real environment.

Two habits that pay off. Log the identifiers rather than the values when you are hunting a scoping bug, because the label tells you which binding you are looking at. And remember that console output is buffered per stream, so interleaving logs from two places can be misleading; a structured logger with timestamps removes that problem.