[NEXT-517] Breakpoint not getting hit in VSCode with Next.js debugger config

[InfiniteLearner]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Pro
    Binaries:
      Node: 16.14.2
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.1.7-canary.7
      eslint-config-next: 13.1.6
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue

https://github.com/InfiniteLearner/debug_error_next_reproduction

To Reproduce

!!!!!!!!!!!!!!!!!!!!! You should be using node v 16.14.2 !!!!!!!!!!!!!!!!!!!!

(Because of other constraints I can not update my node version so this is not an option)

Create a new next.js app
npx create-next-app@latest
Use every default options

Add a new config for debugging in vsCode (.vscode/launch.json):

{
    "version": "0.2.0",
    "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": "started server on .+, url: (https?://.+)",
          "uriFormat": "%s",
          "action": "debugWithChrome"
        }
      }
    ]
  }

Create a new async function in index.tsx and call it (with an onClick for example):

async function greeting(){
    console.log("Hello");
    console.log("Goodbye");
  }

...

<p onClick={greeting}></p>
...

Add a new breakpoint in the function.

Run in debug mode (either server-side, client-side or fullstack).

Describe the Bug

On click of the element, the logs will be displayed without being stop.
The breakpoints are not getting hit.

It should be noted that breakpoints on the returned component are working fine but none in functions.
So if you had a breakpoint on your div (or any other component) it will stop.

Expected Behavior

The breakpoints should get hit and the logs not be displayed.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

_NEXT-517

[jonleung]

I'm having the same problem.

My debugger attaches, it just doesn't stop at a breakpoint

• Operating System:
  • Platform: OSX
  • Arch: x64
  • Version: Ventura
• Binaries:
  -Node: v18.14.0
• Relevant packages:
  • next: 13.1.6
  • eslint-config-next: 13.1.6
  • react: 18.2.0
  • react-dom: 18.2.0

I can't get to pause VS Code or just Chrome

I should also note that I'm using TypeScript

[balazsorban44]

Hmm. I cannot reproduce the OP's issue, we will need to look more into this. @InfiniteLearner attaching a reproduction would be very helpful. 🙏

[jonleung]

Here is me reproducing the issue with Next.js v13.2.3 but I also tested 13.2.2, 13.2.1 13.1.6, 12.3.4 and I could not get anything to trigger a breakpoint:

Here is me starting with npx create-next-app@latest today: https://capture.dropbox.com/sSSjb6nxQGN4Yl43

[HelmerBarcos]

Im also having this problem with all Next.js versions mentioned above.
VScode version 1.76

[HelmerBarcos]

For the next.js version 13.1.6 it will start 2 debuggers after running npm run dev. 1 on port 9229 and another one on port 9230

1️⃣ without dockerized nextjs app

Inside the package.json

    "dev": "NODE_OPTIONS='--inspect' next dev",

Inside the launch.json

    {
      "name": "Attach",
      "address": "127.0.0.1",
      "port": 9230,
      "request": "attach",
      // "localRoot": "${workspaceFolder}/frontend", # just if next app is not inside your root dir
      "skipFiles": ["<node_internals>/**"],
      "type": "node"
    }

If you now attach the vscode debugger, it will recognize breakpoints

2️⃣ with dockerized nextjs app

🚨 You will need to update remoteRoot as well as localRoot if you are working with a monorepo
🚨 You will need to expose the 9230 port by defining it inside the docker-compose.yml file.
You will need to expose the 9230 port by defining it inside the docker-compose.yml file.

Inside the package.json
🚨 Here port 9229 since it will create a 2nd debugger on port 9230. If you assign port 9230 inside the package.json it will probably start 2 dubuggers on 2 ports 9230 and 9231

    "dev": "NODE_OPTIONS='--inspect=0.0.0.0:9229' next dev",

Inside the launch.json

    {
      "name": "Attach",
      "address": "127.0.0.1",
      "port": 9230,
      "request": "attach",
      "localRoot": "${workspaceFolder}/path/to/root", # change this. if the app if in the root dir then ${workspaceFolder} will works. If not then ${workspaceFolder}/subpath does the magic
      "remoteRoot": "/app", # needed. this will be the WORKDIR where the next app is located.
      "skipFiles": ["<node_internals>/**"],
      "type": "node"
    }

Then start the app by defining the command property inside the docker-compose.yml

    command: npm run dev

If you now attach the vscode debugger, it will recognize breakpoints

[gregmartyn]

--inspect=0.0.0.0:9229 doesn't work anymore because https://github.com/vercel/next.js/blob/canary/packages/next/src/cli/next-dev.ts#L524 assumes it can do debugPort + 1 with debugPort = "0.0.0.0:9229"

[gregmartyn]

Opened a separate issue for that: #47083

[ukabu]

For the next.js version 13.1.6 it will start 2 debuggers after running npm run dev. 1 on port 9229 and another one on port 9230

1️⃣ without dockerized nextjs app

Inside the package.json

    "dev": "NODE_OPTIONS='--inspect' next dev",

Inside the launch.json

    {
      "name": "Attach",
      "address": "127.0.0.1",
      "port": 9230,
      "request": "attach",
      // "localRoot": "${workspaceFolder}/frontend", # just if next app is not inside your root dir
      "skipFiles": ["<node_internals>/**"],
      "type": "node"
    }

If you now attach the vscode debugger, it will recognize breakpoints

Node v19.7.0
Next.js v13.2.4

Tried this, yet breakpoints are still no go.

In a .ts file:

> bio-trousse@0.1.0 dev
> NODE_OPTIONS='--inspect' next dev

Debugger listening on ws://127.0.0.1:9229/c488c6b0-d0ad-462a-960b-0d46b92016e0
For help, see: https://nodejs.org/en/docs/inspector
warn  - the --inspect option was detected, the Next.js server should be inspected at port 9230.
Debugger listening on ws://127.0.0.1:9230/520830bc-1763-4201-a714-a034dcb30c1d
For help, see: https://nodejs.org/en/docs/inspector
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
info  - Loaded env from /workspaces/bio-trousse/.env.local
warn  - You have enabled experimental feature (appDir) in next.config.js.
warn  - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use at your own risk.

info  - Thank you for testing `appDir` please leave your feedback at https://nextjs.link/app-feedback
Starting inspector on 127.0.0.1:9229 failed: address already in use
event - compiled client and server successfully in 1778 ms (262 modules)
wait  - compiling...
event - compiled client and server successfully in 504 ms (262 modules)

[ukabu]

I even tried the vscode auto attach feature which attach to all processes (3) when running npm run dev and breakpoints are not good either.

Debugger listening on ws://127.0.0.1:53266/376fb431-e929-47d4-9164-15e2b60c00e6
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.

> bio-trousse@0.1.0 dev
> next dev

Debugger listening on ws://127.0.0.1:53307/a2c5dd46-85ea-44b7-9dcb-503d480fb1bf
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger listening on ws://127.0.0.1:53096/0ade082a-860f-4fe7-820f-decf43d8f1db
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
info  - Loaded env from /workspaces/bio-trousse/.env.local
warn  - You have enabled experimental feature (appDir) in next.config.js.
warn  - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use at your own risk.
info  - Thank you for testing `appDir` please leave your feedback at https://nextjs.link/app-feedback

Debugger listening on ws://127.0.0.1:53243/86f557ca-e973-46cd-ba81-11724d58615d
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Waiting for the debugger to disconnect...
event - compiled client and server successfully in 1882 ms (262 modules)
wait  - compiling...
event - compiled client and server successfully in 585 ms (262 modules)

[ukabu]

Ok, scratch that, with auto attach, it did manage to hit a break point after reloading the app in the broswer.

[asafpelegcodes]

Just wondering how is this not a huge problem for tons of people or why isn't it getting much attention from authors?

[afreemanio]

For people scratching their heads in disbelief over this regression like I was, you can set the debugger to fire manually by hardcoding the option in the node_module:
next/dist/server/next-server.js
Line 168

class NextNodeServer extends _baseserver.default {
    constructor(options){
        options.isNodeDebugging = true; // Added here
        // Initialize super class
        super(options);
        this._validFilesystemPathSet = null;

Then, as in some of the other threads, you have to set the debugger to attach to the second debug port it tells you.
I'm sure there's a way to set the port in a similar way, and this doesn't address the other related issue of not being able to set the address (0.0.0.0), but this at least allowed me to server debug again.

[NullReferenceEric]

I'm also experiencing this issue. Tried

1. modifying next-server.js -no luck
2. tweaking the launch.json - no luck

VSCode version. 1.78
OS: M1 Mac Ventura 13.0

[alxdsz]

Just for the record I'm experiencing the exact same issue in IntelliJ, so maybe it's not even connected to the IDE.
It worked a while ago though (not sure what changed over the time)

[juhahe]

Not sure about the OP, but I think later commenters are experiencing this issue with the current version of next.js. The issue is that next starts several node processes and the debug server is started on the wrong node process. That process does not execute the code where the breakpoint is set, so the debugger never pauses the execution. That's why @ukabu had success with "auto attach feature which attach to all processes". I'm not familiar with this feature myself but attaching the debugger to the process that actually executes the code with the breakpoint would seem to work.

[NullReferenceEric]

Good point. @ukabu can you detail your attach to all processes workflow?

[ukabu]

Just set the Javascript: Auto attach filter to Always in your workspace or user settings.

Then you can start the dev server with npm run dev in a terminal.

[albertlieyingadrian]

Facing the same issue here

[Cow258]

It is worth noting that
We can't hit the breakpoint on the first execution
because the file does not exist there yet or was not compiled
In most cases, the breakpoint can only be triggered normally during the second execution

breakpoint has been added before start the debug process

after start the debug process, but the breakpoint not yet find the code

after start the debug process and execute once, the breakpoint should be triggered on next execution

the breakpoint has been triggered

[lu-zen]

Manually attaching works here:

- info the --inspect option was detected, the Next.js server for app should be inspected at port 32957.
- info the --inspect option was detected, the Next.js server for pages should be inspected at port 35423.

Using CMD+SHIFT+P then Debug: Attach to Node process and selecting the corresponding process.
Didn't have any luck launching via debugger, it attaches to the wrong proccess.

Ps: node v18.16.0

[cesarvarela]

Just wondering how is this not a huge problem for tons of people or why isn't it getting much attention from authors?

This is really baffling, but the reason is that most devs don't know how to use debuggers and rely mostly on logs which is soo inefficient. It is a lost battle at this point.

[nicu-chiciuc]

A thing that doesn't seem to be mentioned is that I'm able to stop the execution in a server function by adding a debugger statement.
Waiting for the first execution to pass then waiting for the 2nd one to attach doesn't seem to work for me.

The issue with the debugger (and I assume breakpoints) is that it stops in a file that has the same contents and name as the actual function file, but it's not the same file (?!).

Note that the file with the debugger doesn't show Git diffs nor breadcrumbs.

I'm using Turborepo so that might add other issues into the mix. I think it would be worth having a sample Next.js repo with clear instructions on how to debug the code.

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.