fix(nextjs): handle process.turbopack is not supported in edge runtime

[asionesjia]

Summary

Fix: Replace direct usage of process.turbopack with a safe fallback using process.env.TURBOPACK.

This resolves the error:

web:build: ./node_modules/.pnpm/@[email protected]_@[email protected]_@[email protected]._08bb47102a2416c860da6a61257d393e/node_modules/@sentry/nextjs/build/esm/edge/index.js:95:9
web:build: Ecmascript file had an error
web:build:   93 |   try {
web:build:   94 |     // @ts-expect-error `process.turbopack` is a magic string that will be replaced by Next.js
web:build: > 95 |     if (process.turbopack) {
web:build:      |         ^^^^^^^^^^^^^^^^^
web:build:   96 |       getGlobalScope().setTag('turbopack', true);
web:build:   97 |     }
web:build:   98 |   } catch {
web:build: 
web:build: A Node.js API is used (process.turbopack at line: 95) which is not supported in the Edge Runtime.
web:build: Learn more: https://nextjs.org/docs/api-reference/edge-runtime

---

Changes

• Replaced all occurrences of process.turbopack with:

export function isTurbopack(): boolean {
  if (typeof process === 'undefined') return false;
  // eslint-disable-next-line @typescript-eslint/no-unsafe-member-access
  return process.env?.TURBOPACK === '1' || !!(process as any)?.turbopack;
}

[Lms24]

Hey, just stepping in with an initial review. I'll leave the final review to @chargome and @RulaKhaled but I had one concern with the change. Can you take a look at that? Thanks!

[Lms24]

According to the comment in src/client/index.ts:

process.turbopack is a magic string that will be replaced by Next.js

which makes me suspect, this function needs to literally contain process.turbopack without any type casts or optional chain operators. If the env variable check solves something in addition, it's fine to keep. But let's maybe just try/catch process.turbopack access instead of checking for definedness?

[asionesjia]

Thanks for the review @Lms24!

You’re absolutely right about the magic string concern.
After checking the Next.js source, I found process.turbopack and process.env.TURBOPACK are always set together. Since process.env.TURBOPACK is safer in Edge Runtime and avoids the magic string issue, I’ve simplified the code to only rely on it.

You can saw the code context diff, process.turbopack and process.env.TURBOPACK

Really appreciate your feedback—please feel free to point out anything else.

[cursor]

Bug: Turbopack Detection Regression

Replacing process.turbopack with process.env.TURBOPACK breaks Next.js's build-time magic string replacement for Turbopack detection. This implementation also doesn't align with the PR description, which proposed a fallback checking both process.env.TURBOPACK and process.turbopack to ensure detection works as expected.

Additional Locations (2)

• packages/nextjs/src/edge/index.ts#L97-L98
• packages/nextjs/src/server/index.ts#L370-L371

 

[asionesjia]

The way to reproduce this problem is to use withSentryConfig in next.config.ts of nextjs 15.5.2(latest) and then execute next build.

[asionesjia]

This problem is only for me, because I've used transpilePackages: ['@sentry/nextjs']. This may not be a Sentry issue..