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 |
@zanhk You may have a secret session running somewhere which might cause this to occur ⬇️ I'd try looking for double process sneaking in somewhere.
It's got its charm. |
|
@dexxiez In the previous snippet I just forgot the other session running, but I have the problem anyway Also with the working example above with webpack it does not hit server breakpoints consistenly |
|
@zanhk hmmm hard one, I don't have much experience with Turbopack myself as it's incompatible with most options I run. I try it every so often to check in on it, and the foot guns come out blazing. I can see you're running Windows which also throws a spanner in the works for me. UNIX based development is definitely getting standardized across the board it seems and probably for good reason. I daily drive Linux so I'm probably biased as all hell here, but there's a reason why all the Tec-bros use Macs. If it's not a compatibility/technical reason and it might be a knowledge gap you might have, I'd look at filling that gap looking into the future of development for you. This is not an excuse for any of this not to work, but us at the bottom of the food chain need to convince technology to work somehow, and UNIX/Linux environments just work a bit better at rolling the dice. WSL is an amazing middle ground between being bankrupt and no lifeing things with daily driving Linux like me. What i just wrote will be probably no help to you whatsoever, but I thought I'd entertain you while someone who knows what they are talking about with Turbo chimes in. |
|
I fixed this by creating a {
"env": {
"NODE_OPTIONS": "--inspect"
}
}This will pass the environment variable only on the Node process that is needed to debug. This is considering also that is run from {
"version": "0.2.0",
"configurations": [
{
"name": "Next.js: debug server-side",
"type": "node-terminal",
"request": "launch",
"command": "npm run dev"
},
]
} |
|
Since @avianion has summoned me, I can't just go past I guess :) A bit late, but sorry, a lot of work. Taking the steps from the original post and amending them a bit to make it more specific, to not involve the client-side debugging parts (I use the server-side
Then:
And in the terminal pane I see (I separate the milliseconds): So what does happen here? You surely understand that you set a breakpoint in a source (TypeScript) file, and So how do the breakpoints ever work then? Then how does Let's bring await new Promise(r => setTimeout(r, 1000)); // 1000 or moreAs for |
You sir
You are an absolute hero... Seeing as we are using the base setup of next its actually baffling without going into the node debugger and seeing that random turbopack folder... why is it not in the docs come on team.... |
This worked perfectly for me. Thanks for posting! |
|
It's very surprising to me that client side, server side, and full-stack debugging is still not working 100% in Next.js 14 using the App Router. Also the documentation (https://nextjs.org/docs/app/building-your-application/configuring/debugging) clearly is just a copy and paste of the stuff from the Pages Router. This suggests to me that debugging has not even been tested properly or prioritized. To Vercel: Please revise the docs. Provide a launch.json that works with the latest version of VSCode. Also, please tell us with screenshots, videos, proper step-by-step on how to setup VSCode. Don't just link to their docs. We as developers should not need to spend an entire day to figure out how to debug our Next.js applications. Enough with the complains. I literally sat the entire day yesterday trying to figure out how the hell VSCode should be setup in order to get both client-side, server side and full-stack debugging properly without any hacky launch.jsons or other work-arounds. When I want to get something working I want to touch as little as possible of the IDE, settings file etc. So here's my solution - it's not perfect but it's the most non-intrusive and one that I can live with in my day-to-day coding: Client-Side, Server-Side, Full-Stack Debugging Next.js 14 (App Router) in VSCodeHow to Debug (Client Side)Note: It's okay to have a regular Chrome browser open while debugging in VSCode. The debugger will attach to a NEW Chrome process that you launch from the terminal.
This command is no magic; it's from the official VSCode docs: https://code.visualstudio.com/docs/nodejs/browser-debugging#_attaching-to-browsers If this is the first time, Chrome will ask if you want to make this your current browser and if you want to send statistics to Google. Select whatever you want in this dialog. The
Note: You can autogenerate the code below by adding a new configuration and selecting "Chrome: Attach". Also, you can copy and paste the code below in a new
Note: I use Clerk as my auth provider and if you use this debugging method, signing in to your Google account via Clerk will work. If you use Nexj.js's method (https://nextjs.org/docs/app/building-your-application/configuring/debugging#debugging-with-vs-code) you will not be able to sign in to your Google account. Keep this in mind when selecting debugging method. How to Debug (Server Side)
How to Debug (Full-stack)I tried this by having two debugging sessions (client side and server side like I explained above) but it worked poorly so I would recommend using one method at a time and not both at once. Notes: In VSCode settings Debug -> JavaScript: Auto Attach Filter should be set to "Disabled" (This is the default setting). I messed around with this setting thinking it might solve some problems but I honestly don't know how it works exactly so I wanted to make sure I reverted it back to its default setting. I hope the above helps someone using Next.js 14+ (App Router) trying to debug both client side and server side code using VSCode's debugger. |
|
I referred to @dmitrc's configuration and successfully used pnpm with turbopack. Below is the launch.json that worked for me. Thanks! // launch.json
{
"version": "0.2.0",
"compounds": [
{
"name": "Debug Start All",
"configurations": ["Launch Chrome", "Start Nextjs"],
"stopAll": true
}
],
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome",
"url": "http://localhost:3000",
"webRoot": "${workspaceFolder}",
"sourceMaps": true,
"sourceMapPathOverrides": {
"/turbopack/[project]/*": "${webRoot}/*"
},
"presentation": {
"hidden": true
}
},
{
"type": "node",
"request": "launch",
"name": "Start Nextjs",
"sourceMaps": true,
"sourceMapPathOverrides": {
"/turbopack/[project]/*": "${webRoot}/*"
},
"runtimeExecutable": "pnpm",
"runtimeArgs": ["run", "dev:turbo"],
"presentation": {
"hidden": true
}
}
]
}// package.json
{
...
"scripts": {
...
"dev:turbo": "next dev --turbo",
},
"dependencies": {
...
"next": "^14.2.7",
},
...
} |
|
Have you guys solved this in server-sider api debugging? |
|
Here's how I got it working using this setup: Next.js 15.0.0.rc (webpack) |
|
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. |
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: