Skip to content

Cannot debug Next15 using turbopack on windows #72789

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
leandroluk opened this issue Nov 14, 2024 · 17 comments · Fixed by #78453
Closed

Cannot debug Next15 using turbopack on windows #72789

leandroluk opened this issue Nov 14, 2024 · 17 comments · Fixed by #78453
Labels
bug Issue was opened via the bug report template. linear: turbopack Confirmed issue that is tracked by the Turbopack team. Turbopack Related to Turbopack with Next.js.

Comments

@leandroluk
Copy link

Link to the code that reproduces this issue

https://github.com/leandroluk/bug-next15-debug-with-turbopack

To Reproduce

  1. Install dependencies
  2. Select "turbo" in "Run and Debug" menu
  3. Select "Browser Debug" in running bar and this error message will appear:

image

  1. When select "webpack" in "Run and Debug" menu and look for "Browser Debug" the error doesnt appear and any breakpoint works.

Current vs. Expected behavior

Are expected to debug works like webpack.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Home Single Language
  Available memory (MB): 32453
  Available CPU cores: 20
Binaries:
  Node: 20.17.0
  npm: 10.9.0
  Yarn: 1.22.22
  pnpm: 9.11.0
Relevant Packages:
  next: 15.0.3 // Latest available version is detected (15.0.3).
  eslint-config-next: 15.0.3
  react: 19.0.0-rc-66855b96-20241106
  react-dom: 19.0.0-rc-66855b96-20241106
  typescript: 5.6.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Turbopack

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

No response

@leandroluk leandroluk added the bug Issue was opened via the bug report template. label Nov 14, 2024
@github-actions github-actions bot added the Turbopack Related to Turbopack with Next.js. label Nov 14, 2024
@piperubio
Copy link

Hi @leandroluk. I'm experiencing the same behavior on my machine with Windows 10, vscode 1.95.2 and npm. Could you consider adding the context that this issue occurs in VSCode and including the launch.json file in your example repo? I hope this helps to resolve the issue. Thanks! 👍

@unstubbable
Copy link
Contributor

Yeah, if you could provide the launch config, we can take a closer look.

@selrond
Copy link
Contributor

selrond commented Dec 11, 2024

Seeing essentially the same issue on Mac.

launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to My App",
      "type": "chrome",
      "request": "attach",
      "port": 9222,
      "urlFilter": "http://localhost:3003/*",
      "sourceMaps": true,
    }
  ]
}

@theceejay123
Copy link

Hello! Just rebumping this issue. Found a couple of things regarding the launch.json and turbopack.

#74002
I closed this one as it was a duplicate of mine. apologies.
But the issue still stands as you really cannot start a debug on vscode (have not tried other IDEs) if you have special characters in your folder structure. Turbopack seems to translate the special characters into url friendly encoded characters.

i.e () would equal to %28 and %29 respectively.

I am currently using this as my launch.json config

    {
      "type": "node",
      "request": "launch",
      "name": "Next.js debug full-stack dev",
      "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/next",
      "runtimeArgs": ["dev", "--turbopack"],
      "env": {
        "NODE_OPTIONS": "--inspect"
      },
      "skipFiles": ["<node_internals>/**"],
      "serverReadyAction": {
        "action": "debugWithChrome",
        "killOnServerStop": true,
        "pattern": "- Local:.+(https?://.+)",
        "uriFormat": "%s",
        "webRoot": "${workspaceFolder}"
      }
    }
  1. Add a breakpoint then hover over the breakpoint. It will now show you that the breakpoint you added is unbounded:

  2. Go to the browser that just opened (this is assuming you have chrome running since it is under debugWithChrome AND using my launch.json setting). Go devtools and under Sources, make sure to group the files into Authored and Deployed

  3. Find your folder structure that has your page.tsx (should be under Authored), and add a breakpoint in the chrome-debugger here:

  4. Now refresh the page and you will find that the file that it opens in vscode is under the _next folder that is dynamically created when you run nextjs 15.

I expect that the breakpoint be hit using the local files given the sourcemap is correct.

Instead what i get is that the file being read/debugged/hit is under _next folder.

Only when adding a
"sourceMapPathOverrides": { "file://B%3A/_devlib/web/with-turbopack-app/": "${workspaceFolder}/" }

And overriding the url-encoded path
will make the breakpoint succeed in getting hit.

Note

The "B%3A" is irrelevant here because that is my drive. BUT a part of the issue because of how turbopack handles the encoding of special characters when trying to map the sourcemaps to its local version.

As of right now. In order for my to bypass the issue of not being able to use turbopack. I remove the line --turbopack in my launch.json config and continue to use webpack as a fallback.

@LeonardoDaLuz
Copy link

This problem happens even without special characters. In fact, I gave up, I'm going to use it without turbopack. Turbopack is fragile.

@uap-dev
Copy link

uap-dev commented Feb 5, 2025

Having issues using attach as well, not sure if it's related to windows or not. A few things I noticed
If I start my dev sever with:

NODE_OPTIONS='--inspect=9231' next dev --turbopack

I get:

Debugger listening on ws://127.0.0.1:9231/97faf0f0-34f0-4446-b55a-f0de7cb0f6d7
For help, see: https://nodejs.org/en/docs/inspector
Debugger listening on ws://127.0.0.1:9232/c418e274-cd72-4080-a9db-b5989111fad2
For help, see: https://nodejs.org/en/docs/inspector
   the --inspect option was detected, the Next.js router server should be inspected at 9232.

None of those debugging ports show up in vscode. However, a port scan shows they are open and listening. I don't know if this is an issue with next or vscode, but I don't normally have issues attaching to debugging ports in other projects.

lsof -i :9231,9232

yields

COMMAND   PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
node    19088 {REMOVED}  18u  IPv4 {REMOVED}      0t0  TCP localhost:9231 (LISTEN)
node    19094 {REMOVED}   19u  IPv4 {REMOVED}      0t0  TCP localhost:9232 (LISTEN)

Running dev server without turbopack is painfully slow for me.

@github-actions github-actions bot added the linear: turbopack Confirmed issue that is tracked by the Turbopack team. label Feb 10, 2025
@AprildreamMI
Copy link

The same issue persists as mentioned in #74002, and there are some discussions here: #64373. Is no one debugging this? Why hasn't such an important issue been fixed yet?

@AprildreamMI
Copy link

The same issue persists as mentioned in #74002, and there are some discussions here: #64373. Is no one debugging this? Why hasn't such an important issue been fixed yet?同样的问题如 #74002 中提到,这里也有一些讨论: #64373 。难道没有人调试这个问题吗?为什么这样一个重要的问题还没有被修复呢?

Very simple projects, including official sample projects, will have this issue.

Image

@JustSuperHuman
Copy link

:'(

@kdy1
Copy link
Member

kdy1 commented Apr 22, 2025

Investigation:

Breakpoints work if I run on Mac or if I attach a breakpoint to the generated file on Windows.

Image

@kdy1
Copy link
Member

kdy1 commented Apr 22, 2025

Related code:

let transform_source = async |src: &mut Option<String>| {
if let Some(src) = src {
if let Some(src_rest) = src.strip_prefix(&prefix) {
*src = uri_from_file(context_path, Some(src_rest)).await?;
}
}
anyhow::Ok(())
};

and

pub async fn uri_from_file(root: Vc<FileSystemPath>, path: Option<&str>) -> Result<String> {
let root_fs = root.fs();
let root_fs = &*Vc::try_resolve_downcast_type::<DiskFileSystem>(root_fs)
.await?
.context("Expected root to have a DiskFileSystem")?
.await?;
Ok(format!(
"file://{}",
&sys_to_unix(
&root_fs
.to_sys_path(match path {
Some(path) => root.join(path.into()),
None => root,
})
.await?
.to_string_lossy()
)
.split('/')
.map(|s| urlencoding::encode(s))
.collect::<Vec<_>>()
.join("/")
))
}

Fixing it would be trivial, but I need to figure out how to extend device space in UTM because I cannot build next.js on my Windows VM at the moment due to ENOSPC. If someone can add code with #[cfg(target_os = "windows")] quickly, it would be nice.

@JustSuperHuman
Copy link

Hey @kdy1 I pushed the fix you mentioned here!

#78430

(First contribution, hope it's what you need!)

@kdy1
Copy link
Member

kdy1 commented Apr 23, 2025

I'm trying to use it, but I'm not sure if those codes are really related. I'll report back after trying it on mac os, which is known to be work.

@JustSuperHuman
Copy link

Ty so much for the patience and doing the heavy lifting (knowing where to start)

I had to make one more change but built locally / tested and its working so far!

Image

@theceejay123
Copy link

Thank you also! Appreciate the big help here!

@kdy1
Copy link
Member

kdy1 commented Apr 24, 2025

Thank you so much for all your help. It really helped 😄 👍

@AprildreamMI
Copy link

Thank!Thank !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue was opened via the bug report template. linear: turbopack Confirmed issue that is tracked by the Turbopack team. Turbopack Related to Turbopack with Next.js.
Projects
None yet
10 participants