How to make Next.js debugging useful?

Question

From the Next.js VSCode debugging page, I got the following launch.json.

{
  "configurations": [
    {
      "name": "Next.js: debug server-side",
      "type": "node-terminal",
      "request": "launch",
      "command": "npm run dev"
    },
    {
      "name": "Next.js: debug client-side",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:3000"
    },
    {
      "name": "Next.js: debug full stack",
      "type": "node-terminal",
      "request": "launch",
      "command": "npm run dev",
      "serverReadyAction": {
        "pattern": "- Local:.+(https?://.+)",
        "uriFormat": "%s",
        "action": "debugWithChrome"
      }
    }
  ]
}

After running the full stack option, Next.js starts like any old npm run dev. The problem is that the debugging isn't very useful. In my debug terminal I have it selected so that there are breakpoints on caught exceptions. In Python applications (where my debugging experience lies), VSCode pauses on the exact line number whenever there is an exception and gives a useful, understandable error.

With Next.js, the breakpoint gives me a complicated, general error that leads to some random Next.js source code. This has next to no meaning for me.

For example, I got a promise rejected error. This is likely from a request I made that was handled with .catch using Axios. Next.js pointed me to the following deeply nested file.

\node_modules\next\dist\server\dev\on-demand-entry-handler.js

On line 202 it caught an error in code which I have never seen before. Upon unpausing the breakpoint, it leads to more of these errors.

How can I make Next.js debug for me more efficiently? I want more clear, understandable errors, that lead me to specific lines of code that I actually wrote.

Cumshaw

Answer 1

this works I just test it. it is different from the original posted here in the nextjs site in these two lines

What I understood from this that instead call the local nextjs script I call my npm from my Windows 11.

And this is debuggin the whole project as well.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Next.js: debug server-side",
      "type": "node-terminal",
      "request": "launch",
      "command": "npm run dev"
    },
    {
      "name": "Next.js: debug full stack",
      "type": "node",
      "request": "launch",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run", "dev"],
      "skipFiles": ["<node_internals>/**"],
      "serverReadyAction": {
        "action": "debugWithChrome",
        "killOnServerStop": true,
        "pattern": "- Local:.+(https?://.+)",
        "uriFormat": "%s",
        "webRoot": "${workspaceFolder}"
      }
    }
  ]
}

Benefield

It's definitely better, but still flawed. It pauses on less useless lines of code, but it still pauses necessarily fairly often. Closer to the experience of Python debugging but still not quite there. This is the best answer for now. – Cumshaw

Answer 2

Solution

I have it selected so that there are breakpoints on caught and uncaught exceptions

Unchecking "Caught Exceptions" will likely lead to the debug behavior you seek.

Explanation

It appears you may have misunderstood what checking "Caught Exceptions" does. Enabling breakpoints on caught exceptions means the debugger will pause on all caught exceptions: your code and all JavaScript dependencies are included (including files like \node_modules\next\dist\server\dev\on-demand-entry-handler.js)

On line 202 it caught an error in code which I have never seen before. Upon unpausing the breakpoint, it leads to more of these errors.

This is expected behavior, as try/catch statements are standard practice in JavaScript to catch unexpected behavior and errors, and therefore the debugger pauses on all of these statements as long as Caught Exceptions is checked. A catch statement implies an expected error occurred, so pausing on it may not make sense in your debug case!

Breaking on uncaught exceptions is more likely to pause on meaningful errors and exceptions, meaning that an unexpected error was thrown and not caught inside of a try/catch statement. It's likely that dependencies will not have any uncaught exceptions (if they do then it may be considered a bug), hence allowing the debugger to catch mistakes mainly within your code.

Entryway

Looking back, I probably shouldn't have mentioned that I had uncaught exceptions checked, as it made my question more complicated than it should be. Next.js debugging remains frustrating whether uncaught is checked or not. The fact that uncaught exceptions was checked was just a pedantic detail specific to my use case. I've edited my post to reflect this, but I thank you for your input anyways. – Cumshaw

I meant caught exceptions checked, not uncaught. – Cumshaw