nextjs - 💡(How to fix) Fix MIDDLEWARE_INVOCATION_FAILED on Vercel deploy: Cannot find module @swc/helpers/esm/_interop_require_default.js — minimal repro: [email protected] + proxy.ts + top-level @sentry/nextjs import

Link to the code that reproduces this issue

https://github.com/Makturk/next-16-proxy-swc-helpers-repro

To Reproduce

git clone https://github.com/Makturk/next-16-proxy-swc-helpers-repro.git
cd next-16-proxy-swc-helpers-repro
npm install
npm run build      # PASS locally
npm start          # PASS locally

Deploy to Vercel (default framework preset "Next.js", any region, any plan):

npx vercel --prod

Request the deployed URL.

Live failing deployment (running on commit 2768e57): https://next-16-proxy-swc-helpers-repro.vercel.app/

Response: HTTP 500 — MIDDLEWARE_INVOCATION_FAILED A server error has occurred fra1::<request-id>

Vercel runtime log (vercel logs --json):

{
  "source": "serverless-middleware",
  "level": "error",
  "responseStatusCode": 500,
  "message": "Cannot find module '/var/task/node_modules/@swc/helpers/esm/_interop_require_default.js'\nDid you forget to add it to \"dependencies\" in `package.json`?\nNode.js process exited with exit status: 1."
}

Current vs. Expected behavior

Current behavior

A clean [email protected] project with a 3-line src/proxy.ts middleware and a single top-level import * as Sentry from '@sentry/nextjs' in src/instrumentation.ts builds locally without warning, starts locally without warning, and fails on Vercel with: Cannot find module '/var/task/node_modules/@swc/helpers/esm/_interop_require_default.js'

node_modules/@swc/helpers/esm/_interop_require_default.js exists in the install tree. The local build artifact does not reference the ESM path. Vercel's runtime resolver still tries to require it.

Removing the Sentry import line from instrumentation.ts (no other change) makes the deploy succeed. Adding the line back reproduces the crash. The Sentry value is never invoked; the static import alone is sufficient.

The same crash appears in a larger production codebase (Makturk/shade-quote) where the same trigger conditions hold. Renaming src/proxy.ts to src/proxy.ts.disabled so Next.js skips middleware registration entirely shifts the error code to FUNCTION_INVOCATION_FAILED on / with the identical stack trace — i.e. the missing module is requested from every Vercel function execution path, not just the middleware function.

Expected behavior

The function should serve requests without a missing-module error, or the build pipeline should refuse the deploy with a clear error if a runtime dependency is unsatisfiable.

Falsification already performed (on the production codebase)

Full chain in docs/sprints/2026-sprint-24/step-3-vercel-support-evidence.md. ~5.5 hours, 9 hypotheses falsified. Highlights:

• Vercel Framework Preset already "Next.js"; Build Cache Clear does not help.
• outputFileTracingIncludes does not affect the middleware NFT (consistent with the Next.js docs note about Edge Runtime routes).
• webpack.autoInstrumentMiddleware: false does not remove Sentry from the Edge bundle.
• Dropping withSentryConfig + emptying sentry.edge.config.ts + commenting out the Edge dynamic import in instrumentation.ts still leaves the Edge chunk source map listing 50+ @sentry/core files because of the top-level import * as Sentry from '@sentry/nextjs'.
• Lazy import('@sentry/nextjs') inside a process.env.NEXT_RUNTIME === 'nodejs' guard makes the Edge bundle LARGER (Turbopack defensively bundles Sentry).
• Removing every Sentry reference reduces the Edge bundle to 100 KB with mathematical zero @sentry / @swc/helpers source map entries. Same crash on Vercel.
• Downgrading to [email protected] reproduces.
• Fresh rm -rf node_modules package-lock.json && npm install (bumps Sentry 10.48.0 → 10.53.1, Supabase 2.99 → 2.105 within existing ^ ranges) reproduces.
• Adding @swc/helpers as an explicit dependency at the version pinned in overrides (0.5.21) does not help.

Why we believe this is a platform-level issue

Same module path missing across two distinct function types (middleware function and page-render function) with the same stack trace points to the framework runtime bundling layer that sits beneath both function types. Local Turbopack output is clean; only Vercel's deploy-time pipeline produces the missing runtime require.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: macOS local; Vercel `fra1` region for the failing deploy
Binaries:
  Node: 20.x (Vercel runtime default) / 24.14 (local)
  npm: 11.9
Relevant Packages:
  next: 16.2.6
  react: 19.2.4
  @sentry/nextjs: 10.48.0
  @swc/helpers: 0.5.21 (also pinned via `package.json` `overrides`)
Next.js Config:
  output: <default>
  File convention: src/proxy.ts (Next.js 16 middleware convention,
                   previously src/middleware.ts)

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

Runtime

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

Vercel (Deployed)

Additional context

Hosting: Vercel (Hobby plan, region fra1).

Tested canary: No. The minimal repro reliably reproduces on [email protected] and [email protected] stable. Will retest against canary if a maintainer requests it.

Prior auto-closed issue

#93850 (2026-05-14, closed by github-actions bot within 18 seconds, invalid link label because the original repro link pointed at the production business-code repo rather than a template-fork repo). This issue is the resubmission with a template-pattern minimal-reproduction repository:

• Public minimal-reproduction repository, scaffolded with [email protected] (App Router, TypeScript, src/ layout).
• Total surface beyond the template:
  • src/proxy.ts — 3-line pass-through middleware (return NextResponse.next(), matcher /)
  • src/instrumentation.ts — import * as Sentry from '@sentry/nextjs' at the top, plus void Sentry to defeat tree-shaking. Otherwise a no-op register().
  • src/app/page.tsx — single-line component
  • package.json overrides: @swc/helpers pinned to 0.5.21 (matches transitive default, kept explicit to match production)

What we're asking

1. Is this a known issue, and is there an open patch?
2. Is there a known workaround (a next.config.ts opt flag, a Vercel project setting, or a structural change we could make)?
3. If this is a new issue, is the right escalation path: (a) vercel/next.js for the framework bundling pipeline, or (b) Vercel Support for the deploy-time wrapper that requests the missing ESM path?