-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Description
Link to the code that reproduces this issue
https://github.com/vercel/turborepo/tree/main/examples/basic
To Reproduce
- Use
npx create-turbo@latestas instructed in the example'sREADME - Select
pnpmas the package manager - Start the apps using
pnpm dev - Open the docs site at
https://localhost:3001 - Open the Segment Explorer from the Next.js Dev Tools (click the button in the bottom left corner and select Route Info)
- Hover over either
layout.tsxorpage.tsx, then click on the code icon
Current vs. Expected behavior
I expect my editor (in my case, Visual Studio Code) to open the selected file. Instead, nothing happens. Inspecting Chrome Dev Tools, I see a 404 error from a request to http://localhost:3001/__nextjs_launch-editor?file=%2Fapps%2Fdocs%2Fapp%2Flayout.tsx&isAppRelativePath=1.
Provide environment information
Operating System:
Platform: linux
Arch: arm64
Version: #1 SMP Thu Aug 14 19:26:13 UTC 2025
Available memory (MB): 15973
Available CPU cores: 12
Binaries:
Node: 22.16.0
npm: 10.9.2
Yarn: 1.22.22
pnpm: 9.0.0
Relevant Packages:
next: 16.0.2-canary.4 // Latest available version is detected (16.0.2-canary.4).
eslint-config-next: N/A
react: 19.2.0
react-dom: 19.1.0
typescript: 5.9.2
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
Notably, the path given to /__nextjs_launch-editor is from the root of the monorepo rather than from the Next.js app's app directory, which I think is what's causing the issue, given this code:
next.js/packages/next/src/next-devtools/dev-overlay/components/overview/segment-explorer.tsx
Lines 444 to 456 in 138c9ae
| function openInEditor({ filePath }: { filePath: string }) { | |
| const params = new URLSearchParams({ | |
| file: filePath, | |
| // Mark the file path is relative to the app directory, | |
| // The editor launcher will complete the full path for it. | |
| isAppRelativePath: '1', | |
| }) | |
| fetch( | |
| `${ | |
| process.env.__NEXT_ROUTER_BASEPATH || '' | |
| }/__nextjs_launch-editor?${params.toString()}` | |
| ) | |
| } |
next.js/packages/next/src/server/dev/middleware-turbopack.ts
Lines 367 to 379 in 138c9ae
| } else if (pathname === '/__nextjs_launch-editor') { | |
| const isAppRelativePath = searchParams.get('isAppRelativePath') === '1' | |
| let openEditorResult | |
| if (isAppRelativePath) { | |
| const relativeFilePath = searchParams.get('file') || '' | |
| const appPath = path.join( | |
| 'app', | |
| isSrcDir ? 'src' : '', | |
| relativeFilePath | |
| ) | |
| openEditorResult = await openFileInEditor(appPath, 1, 1, projectPath) | |
| } else { |
As instructed by next info, I updated to the latest canary version of Next.js and was still able to reproduce the issue.
I tried changing turbopack.root in next.config.ts, assuming that this is being defaulted to the monorepo root due to where pnpm-lock.yaml is placed. Unfortunately, this causes other issue, namely that Turbopack can no longer resolve next/package.json (probably because of how pnpm symlinks packages).