Debugger not binding breakpoints in VSCode in server components, using official Next.js debugger setup #62008
Comments
andrewmartin
changed the title
|
I've been facing the same issue, and ultimately the discussion in #56702 is what helped me solve it. Add the following If you're not using Turbopack, replace I definitely did not need to do this back in the day ( |
|
Thanks @dmitrc , and thank you for referencing #56702 which I found helpful too I actually tried this and it still didn't seem to pick things up. Keep in mind I'm specifically working with server files, e.g. To be doubly clear, I'm hoping to debug against server code in Next.js, not just the browser. I'm wondering if there's some other path to consider to include or index on the sourcemaps from |
|
@andrewmartin, just to confirm, while the other thread is named "client-side debugging", for my case I was actually also looking to fix the issues with debugging server files specifically ( |
|
@dmitrc totally I get it. Thanks much. I still am struggling :( |
|
I hope your thread can get some attention from the team -- debugging is such a core part of development experience, it's in everyone's best interest to get this fixed and/or clarified ASAP. Best of luck with your scenario! |
|
Thanks a lot and totally agree! It worked so nicely before next 14. |
|
Just so y'all know, this did not work for me. @dmitrc did this work for you with API endpoints (not just the actual |
|
Neither worked for me, tried to follow @dmitrc suggestion but this didn't work for me, that unacceptable, can we fix it, please P.S. https://nextjs.org/docs/pages/building-your-application/configuring/debugging just being stupid and not reading the docs, actually it worked perfectly by setting |
|
Also struggling with this, can't manage to make server side debugging work |
|
@andrewmartin still getting this issue when using turbopack on server files with the vscode debugger, did ou fix it |
|
having the same problem as well, does anyone found a solution? |
|
@x-yuri |
|
@avianion Yeah, still hitting it unfortunately. I kinda gave up. It's odd because some projects, it works totally fine, like the |
|
The .js files seem to be generated fine, but the corresponding .map files are not found. See here my debugger says Could not read source map for file:///app/nextjs/.next/server/chunks/e95bda..js: ENOENT: no such file or directory, open 'c:\Users\my_user\Desktop\my_app\nextjs\nextjs.next\server\chunks_e95bda._.js.map' however the e95bda..js file is itself present, just not the map. |
|
@albert-kovalevskij Had the solution for me. This only affects those using turborepo. "P.S. https://nextjs.org/docs/pages/building-your-application/configuring/debugging just being stupid and not reading the docs, actually it worked perfectly by setting "cwd": "${workspaceFolder}/apps/web" for turporepo" |
|
I've been unable to get …this results in the parent I was able to at least get debugging working by starting plain This is a painful workaround; something in Next needs to be fixed to make debugging work properly. |
|
In all scenarios debugger attaches for me just fine but breakpoints do not bind. I'm guessing is just related to it being unable to find the files. I'm using these configs: {
"name": "Next.js: Attach",
"port": 9230,
"request": "attach",
"skipFiles": ["<node_internals>/**"],
"type": "node",
"localRoot": "${workspaceFolder}/my-app/src"
},
{
"name": "Next.js: debug server-side",
"type": "node-terminal",
"request": "launch",
"command": "npm run dev",
"sourceMaps": true,
"sourceMapPathOverrides": {
"webpack://_N_E/*": "${webRoot}/*"
},
"cwd": "${workspaceFolder}/may-app"
},Nothing seems to work |
|
Hi all, I've just been down this rabbit hole and its terrible. By a stroke of luck, I could get it working. I might be repeating what is already said here, just from a different perspective which may help someone. Full degression, running Next This is the first time I've actually been able to get a NodeJS application actually to debug, and I can't believe it. My environment is turborepo (soon to be nx, but thats another story). I can confirm my relative path to next is My symptoms were a lot the same as the others here, client side is perfect, server side might as well be located in Mars for all I knew. I looked in the NodeJS debug tool and saw that only a subset of my server files were actually being exposed.
After actually using my eyes 👀 I saw this. Now call me stupid or ADHD riddled, but I stopped looking normally at the first line mentioning port 9229. It sneaks in 9230 which i found the NodeJS debug tool via Chrome does NOT add by default. At this point I didn't go straight to vscode. I stayed with the Node debugger to do some more testing. I added it in.
After adding it in and probably restarting the dev server with the documented normal command via Package JSON script {
....
"scripts": {
"debug": "NODE_OPTIONS='--inspect' next dev",
}
...I looked at the sources tab in Node Devtools
and it actually had
I ran the code, and the breakpoint tripped. I thought I was tripping instead to be honest, this is the closest I've ever gotten. Only now did I go back to VSCode DebugI made the new debug file which I've rage deleted many times. {
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "attach",
"name": "Attach to Node",
"port": 9230,
"skipFiles": [
"<node_internals>/**"
],
"cwd": "${workspaceFolder}/apps/web" // I have this because it lives in subfolders, if you're soloing it with no monorepo, you can remove this
},
// Below is irrelevant to this post but whatever
{
"name": "Next.js: debug client-side",
"type": "chrome",
"request": "launch",
"url": "http://localhost:3000",
"cwd": "${workspaceFolder}/apps/web",
},
]
}IMPORTANT SIDE NOTE: This does not start your dev server, it purely connects to what is running, so start your dev server with inspect as per previous Package JSON mention. The debugger attached but breakpoints are still not red/are hollow with no fill. I tried it anyway, and it worked.
Things that did not work for me
Things that may be useful troubleshootingEveryone mentions {
"version": "2.0.0",
"tasks": [
{
"label": "echo",
"type": "shell",
"command": "echo ${workspaceFolder}"
}
]
}I hope this helps you on your journey of accelerated hair loss. |
|
Hi all, I just wanted to add what I've been using with the app router to get my debugging working as similar to the pages method in the docs. The main thing ive added compared to other suggestions is the ability to debug the full stack in one task. Tested on Windows with WSL(ubuntu) and using the regular VSCode {
"version": "0.2.0",
"configurations": [
{
"name": "Next.js: debug server-side",
"type": "node-terminal",
"request": "launch",
"command": "npm run dev --turbo"
},
{
"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 --turbo",
"skipFiles": ["<node_internals>/**"],
"sourceMaps": true,
"sourceMapPathOverrides": {
"/turbopack/[project]/*": "${webRoot}/*"
},
"serverReadyAction": {
"action": "debugWithEdge",
"killOnServerStop": true,
"pattern": "- Local:.+(https?://.+)",
"uriFormat": "%s",
"webRoot": "${workspaceFolder}"
}
}
]
} |
|
Here to say that I finally got this working after a bunch of frustration (using node inspector, I don't tend to use vscode for js debugging usually). The big key was this comment so thank you @dexxiez Some notes on that
Therefore the trick seems to be to first of all add the appropriate connection, but then also to launch the process, let pages load, and only then try to connect to it via the debugger. |
|
A very simple setup that got it working for me. In then I run my project in And then run attach in VSCode. Breakpoints are working! Note that ports do not match – I don't know why but node was always starting on port+1 on specified!! (you can see actual port it started in the console). |
|
@dmitrc it actually worked with your config. what a ride! took me ages to find your answer. thank you! |
|
I tried so many things. I am running a TS monolithic Next.js app, and turns out all I needed to do was turn on auto-attach VSCode feature and launch the app from the VSCode terminal. No configurations or changes, I deleted everything - just run |
The same is true for most projects. If you have it to auto-attach "always," there is a good chance it will work when you run it from the terminal. It needs to be "always," apparently, because sometimes a process will launch another and another, and apparently, "always" covers those cases. In other cases, for instance, in my case, we use turborepo, so we had to do the mapping described by @dmitrc The browser code is slightly different because the browser needs to be launched with the parameters to allow remote connection on the Chrome inspector. |
|
Does someone have a sample repo where debugging work on windows with turbopack? |
try this .vscode/launch.json {
"version": "0.2.0",
"configurations": [
{
"name": "Next.js: debug server-side",
"type": "node-terminal",
"request": "launch",
"command": "pnpm run dev",
"sourceMaps": true,
"sourceMapPathOverrides": {
"/turbopack/[project]/*": "${webRoot}/*"
}
},
{
"name": "Next.js: debug client-side",
"type": "chrome",
"request": "launch",
"url": "http://localhost:3000",
"webRoot": "${workspaceFolder}",
"sourceMaps": true,
"sourceMapPathOverrides": {
"/turbopack/[project]/*": "${webRoot}/*"
}
}
]
} |
|
Thanks @0x33dm but unfortunatly with that configuration it does not work With either It doesn't hit neither the breapoints on server side neither the ones on client side The only way i got it to work is without using turbo with this config {
"version": "0.2.0",
"configurations": [
{
"name": "server",
"type": "node-terminal",
"request": "launch",
"command": "bun run dev"
},
{
"name": "client",
"type": "chrome",
"request": "launch",
"url": "http://localhost:3000"
},
{
"type": "node",
"request": "attach",
"name": "attach",
"port": 9231,
"skipFiles": ["<node_internals>/**"]
}
],
"compounds": [
{
"name": "Debug Server and Client",
"configurations": ["server", "client", "attach"]
}
]
}
But with webpack is slow af |
|
For anyone using > Next.js 14.2, the source map path has changed, per #63740 (comment): I'm running the 14.2.3 canary and breakpoint debugging suddenly broke. Changing the |
|
For people using Here is what works for me: thanks to #62008 (comment) |
This worked for me. It even worked for server actions. I am using |
Thanks you @Rexiao. This worked for me on 14.2.15 as well. It's the only code that worked. My package.json script is
|
|
This worked for me after some time (using Nx):
...
{
"name": "Next.js: debug server-side",
"type": "node",
"request": "attach",
"sourceMaps": true,
"port": 9230, // Note the port is not the default 9229
"cwd": "${workspaceFolder}/apps/my-app",
"sourceMapPathOverrides": {
"webpack:///./*": "${webRoot}/apps/my-app/*"
}
...
...
"serve": {
"command": "cross-env NODE_OPTIONS='--inspect' next dev",
"defaultConfiguration": "development",
"production": {},
"staging": {}
}
...Then I would launch |
|
This is what ended up working for me. Using webpack-internal instead. Also, not using the standard port 9229 due to how I have things set up. I found this running the chrome node inspector, hooking it up to the correct port, setting a break point that successfully triggered. Then opening the terminal debugger with node inspect localhost:9230 and triggering the break point and node inspector output the file path of the break point There may be an easier way to find this info but worked for me |
Thank you, this is also working on my side now. I also had the feeling that there are to many processes started for debugging on different ports, however just attaching the VSCode to the 9230 running process is the easiest way. |
this set up it's working for me. the only thing i didn't manage to make it open the terminal in the editor code, so i have the debugger, but not the terminal |
|
Thanks @TechGeorgii for your post, I was bashing my head against a wall b/c the attach to port option used to work for me then stopped after some upgrades. The trick for me was your comment :
I have the following in package.json : I switched my attach to port config to use 9232 and it worked! Development accelerated! Debug config for those who want to try it out : |
|
For anyone struggling to debug server-side - I spend a few hours trying various configs, and nothing worked, before arriving at something that actually worked and was more or less convenient: It's a shame that the example from the docs did not work out of the box. P.S. Config is inspired by this - https://gist.github.com/tomdohnal/9a251c4e25136213509e5b1293ffc641, many thanks to the author. I just added launching the app to the compound. |
this breakdown is absolutely insane. everything was identical on my end, down to the emotional rollercoaster. Thank you! |
|
thanks @nameofname Serverside debugging with Windows turbopack config, PS: Stopped working |
thank you, i am using nextjs 15 and encounter issue when debugging server API, this code works for me! and yest the terminal does not open |
|
I wrestled with it for a long time but couldn't get it work no matter what sourceMapOverride I set. I solved it eventually by calling {
"name": "Next.js: Server",
"type": "node-terminal",
"request": "launch",
"cwd": "${workspaceFolder}/apps/web",
"command": "npx next dev",
"env": {
"NODE_OPTIONS": "--inspect"
},
"skipFiles": [
"<node_internals>/**"
],
},Another thing that help was to add a function() {
// ....
debugger;
// ...
}It seems the debugger confuses the code path thinking the source code is at |
{
"name": "Next.js: debug server: launch",
"type": "node",
"request": "launch",
"cwd": "${workspaceFolder}/packages/web-next",
"program": "${workspaceFolder}/packages/web-next/node_modules/next/dist/bin/next",
// "args": ["dev", "--turbopack"],
"args": ["dev"],
"runtimeArgs": ["--inspect"],
"skipFiles": [
"<node_internals>/**",
"${workspaceFolder}/node_modules/**",
"${workspaceFolder}/packages/web-next/node_modules/**"
]
}Had a similar config and running into the same issue where the turbopack flag prevents certain breakpoints from being reachable. My middleware breakpoints can be hit with ["dev", "--turbopack"], but not my server component code. That only works when I run dev without the turbopack flag, but the dev server is so slow its almost unusable without turbopack. |
{
"name": "Next.js: debug full stack",
"program": "${workspaceFolder}/my-app/node_modules/next/dist/bin/next",
"args": [
"dev",
"--turbopack",
],
"runtimeArgs": [
"--inspect"
],
"skipFiles": [
"<node_internals>/**",
],
"type": "node",
"request": "launch",
"sourceMaps": true,
"serverReadyAction": {
"killOnServerStop": true,
"webRoot": "${workspaceFolder}/my-app",
"pattern": "- Local:.+(https?://.+)",
"uriFormat": "%s",
"action": "debugWithChrome"
},
"sourceMapPathOverrides": {
"file://C%3A/WORK/VSCODE/PROJECTS/my-app/*": "${workspaceFolder}/my-app/*",
"start-server.js/*": "${workspaceFolder}/*",
},
"cwd": "${workspaceFolder}/my-app",
}After try and errors this works for me with --turbopack. Im not actually sure why and how. This is my first attempt to debug nextjs with actual debugger instead of console.log.
I figured out that when i run with turbo, i get encoded C%3A instead of C: in chrome dev tools -> sources. Then i check vscode "Loaded Scripts" tab.
and it works for me. Client side is related to #73384 i think. So check your "dev-tools -> sources" and vscode Loaded Scripts for client and server side files and adjust path in overrides accordingly. |
|
This issue is looking like my discussion here as well as my issue that I attempted to open here. After PR #71940, merged in v15.0.3-canary.4, breakpoints no longer line up on server side code. The From what it looks like on this chat, people are working around the bug by trying to patch their webpack configurations. |
This worked for me to open the terminal: |
|
This is how I got it working for Next.js 15.2:
|
|
On another computer, a Mac, my previous configuration for an nx mono repo app didn't work, so this time I had to use this for the app to pick up the correct paths to the files on the disk: {
"name": "Next.js: debug server-side",
"type": "node",
"port": 9230,
"request": "attach",
"cwd": "${workspaceFolder}",
"sourceMapPathOverrides": {
"webpack-internal:///(rsc)/*": "apps/my-app/*"
}
}Strangely the same |
Is there a workaround for IDE's outside of VS Code? I am still pinning to this older version because of the bug. @icyJoseph ? |
|
@icyJoseph with the big security vulnerability we are now forced to chose between secure and debuggable. Is it possible to revert #71940 so we have something to work with? |
|
Still does not work with Turbopack in latest versions (on Windows): With default settings, web app is using Turbopack: Server-side debugging with https://nextjs.org/docs/app/building-your-application/configuring/debugging settings do not work - breakpoints are not active. If Turbopack is disabled during |
|
Thanks to @nomtats I was able to debug effectively 🎉 What worked for me was to put directly into my code the
If you're wondering here's my (Using cwd since I'm in a monorepo) And here's my As you can see, I'm still using TurboPack which allows to compile faster. I hope this helps some of you to debug until this issue is fixed! |
|
Update: I was able to make the fullstack debugger work 🎉 BUT the UX has confused me. When setting the breakpoints and launching the debugger they look unbound. On my side, client code, server components and server actions could be debugged properly. Here's my configuration: |
|
I'm also unable to get this to work, and I've tried all sorts of variations that others have suggested with no luck. Here's my launch.json config: {
"name": "Website",
"type": "node",
"request": "launch",
"runtimeExecutable": "pnpm",
"runtimeArgs": ["exec", "turbo", "run", "web#dev"],
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen",
"restart": false,
"serverReadyAction": {
"pattern": "- Local:.+(https?://.+)",
"uriFormat": "%s",
"action": "debugWithEdge",
"killOnServerStop": true,
"webRoot": "${workspaceFolder}/apps/web/src"
}
},
I'm using turborepo and my monorepo is set up as one would expect: apps/web is the folder for the nextjs site, and apps/web/src has the source code in it. |
|
The year is 2025. Full-stack web developers are still being forced to write I'm definitely surprised to see this is an active issue. One of the reasons I chose this framework and toolset was to ensure a painless development experience, but I'm losing valuable time fighting through seemingly simple issues. There are a lot of suggestions above. Has there been any definitive progress towards a solution, or is there at least a workaround that doesn't send us back in time? |
I've spent two days trying to come up with a monorepo setup that supports:
For a monorepo using Typescript, nextjs for the app, expressjs for the API server, and two basic packages. I swear this must be the most common configuration for people writing a frontend and backend in Typescript. And yet. AND YET. I got nowhere. Got so annoyed I even went on a Twitter rant about it. You can see my continuing descent into madness in my personal open issue on it. |
|
Hi, guys! any updates here? for today, using setup from official documentation https://nextjs.org/docs/pages/guides/debugging: |
Thanks, tis worked for me 🥳 Not in a monorepo, here's my config: Also not seeing my server-side breakpoints light up, but they get hit and I can debug normally. |
and others
Link to the code that reproduces this issue
https://github.com/andrewmartin/nextjs-example
To Reproduce
VSCodeBreakpoints set in server components that aren't attached (sorry the screencaps below didn't show my mouse hover so here's a gif):
Debug diagnostics:
Some of the sources loaded (I can provide more if needed):
Current vs. Expected behavior
Hi everyone! The code repo shared is a brand new, blank
create-next-appusing Typescript, Next14, and theappdirectory. I only added the debugging setup from the official docs and a single basic API endpoint at/api/healthand that's it. For some reason I cannot for the life of me get my breakpoints to attach.Well, that's partially true, The only breakpoints that seem to be mapped with my codebase are those in the Browser / client side components. I have tried SO many things to get this to work and have read probably about 30 posts about trying to fix this.
I'd love to know if anyone has any ideas why a vanilla Next.js project might not find my sources. Thanks in advance for your help!
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6000 Binaries: Node: 20.11.0 npm: 10.2.4 Yarn: 1.22.21 pnpm: N/A Relevant Packages: next: 14.1.0 eslint-config-next: 14.1.0 react: 18.2.0 react-dom: 18.2.0 typescript: 5.3.3 Next.js Config: output: N/AWhich area(s) are affected? (Select all that apply)
Not sure
Which stage(s) are affected? (Select all that apply)
next dev (local)
Additional context
I have tried:
sourceMapPathOverridesetcSome of my colleagues have had luck seeing them, others have not.
The text was updated successfully, but these errors were encountered: