Cannot debug Next15 using turbopack on windows

[leandroluk]

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:

4. 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

[piperubio]

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]

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

[selrond]

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]

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]

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]

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.

[AprildreamMI]

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]

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.

[JustSuperHuman]

:'(

[kdy1]

Investigation:

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

[kdy1]

Related code:

next.js/turbopack/crates/turbopack-core/src/source_map/utils.rs

Lines 178 to 185 in 98e61ef

	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

next.js/turbopack/crates/turbo-tasks-fs/src/util.rs

Lines 141 to 164 in 98e61ef

	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.