nextjs - 💡(How to fix) Fix Turbopack: empty middleware-manifest for proxy.ts on Next 16.2.4 / 16.3.0-canary.3 (Windows; root and src/ placement) [1 participants]

Link to the code that reproduces this issue

https://github.com/babihacare/next-proxy-manifest-bug

To Reproduce

1. git clone https://github.com/babihacare/next-proxy-manifest-bug
2. cd next-proxy-manifest-bug && npm install
3. npm run build
4. Inspect .next/server/middleware-manifest.json — observe "middleware": {}.
5. Rename root proxy.ts to root middleware.ts and rename the export from proxy to middleware.
6. Rebuild — manifest now contains "middleware": { "/": { ... } } and the build summary prints ƒ Proxy (Middleware).

Current vs. Expected behavior

Current: With proxy.ts at the project root (or at src/proxy.ts), Turbopack writes an empty .next/server/middleware-manifest.json:

{
  "version": 3,
  "middleware": {},
  "sortedMiddleware": [],
  "functions": {}
}

The build summary silently omits any "Proxy (Middleware)" line — no warning, no error, no log. At runtime the proxy is skipped: in the linked reproduction, the x-proxy-ran header never appears on /admin responses.

Expected: With proxy.ts (the Next 16 convention), the manifest should be populated with the matcher entry, the build summary should print ƒ Proxy (Middleware), and the proxy should run at runtime — same as the file rename test above demonstrates with middleware.ts.

Verified on both stable 16.2.4 and canary 16.3.0-canary.3. Both proxy.ts (root) and src/proxy.ts placements produce the empty manifest. The workaround — root middleware.ts with export middleware — works on both versions.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Home
Binaries:
  Node: 25.9.0
  npm: 11.12.1
Relevant Packages:
  next: 16.3.0-canary.3
  react: 19.2.5
  react-dom: 19.2.5
  typescript: 6.0.2
Next.js Config:
  output: N/A

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

Middleware, Turbopack

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

next build (local), next start (local), Vercel (Deployed)

Additional context

• Same symptom as the now-locked #85243. The github-actions bot in that thread directs new reporters to open a fresh issue.
• PR #85443 (cited as the fix in #85243) does not resolve the bug for this reproduction on either 16.2.4 or 16.3.0-canary.3.
• Workaround: keep the file as root middleware.ts with export middleware. Production deploys to Vercel work correctly with that layout.
• Refile of #93326 (auto-closed because the body sections were not in the template's required order — this issue uses the canonical structure).