Next.js Turbopack Support

[ryanolson-aumni]

⚠️ This original post has been edited by @lforst to reflect the current status of Turbopack Support ⚠️

Important

This issue is tracking progress on Turbopack Support. If you find bugs or problems with the Sentry SDK in combination with Turbopack please open a separate issue. Thank you!

Problem Statement

Sentry should work in combination with Turbopack with all of its features.

Current Status (Last Update Nov 6, 2024)

Feature	Support	Notes
Next.js app compiles and runs without issues	✅
Server-side instrumentation	✅
Client-side instrumentation	❌	Doable with a little bit of setup - slightly/very hacky - needs documentation
Source Maps	❌	- Needs onBuildEnd hook implemented in Next.js - Needs way to inject debug IDs into bundles implemented in Next.js
React Component Name Annotations	❌	- Needs way to transform code in Next.js
Release Injection	❌	As a user you probably don't care about this one, but it will become relevant once Turbopack prod builds are a thing. We will likely solve this with v9 of the SDK (coming Jan 2025).

[smeubank]

Hi @ryanolson-aumni

We are also eager to add support here!

We have 2 plugin repos to add support for webpack, esbuild, rollup, and vite. The latter 3 we support via an opensource project where we'd love to see support so we could potentially adopt it via our usage of their adapters. Upvote the issue there as well. Although I do not think it is on their immediate radar either. unjs/unplugin#302

https://github.com/getsentry/sentry-webpack-plugin

https://github.com/getsentry/sentry-javascript-bundler-plugins

[mdugue]

any news on this?

[lforst]

@mdugue We'll tackle turbopack when it becomes somewhat stable.

[smeubank]

any news on this?

Fwiw I would also encourage you to upvote and comment on this issue which wr could also use to provide support similar to webpack, vite, esbuild and rollup

unjs/unplugin#302

[lforst]

Update

As of now, we cannot transfer the functionality we currently have in the SDK to Turbopack:

Turbopack loaders are not passed transpiled javascript, instead, they are passed the original user code. The SDK needs transpiled JS to properly be able to do transformations to modules. We could transpile the user code ourselves but that is fragile AF - so not an option.

As of now, the SDK will continue to work in production mode which is arguably more important, but we would like to support dev mode.

Branch with my experiments: #9295

[Stanzilla]

Update

As of now, we cannot transfer the functionality we currently have in the SDK to Turbopack:

Turbopack loaders are not passed transpiled javascript, instead, they are passed the original user code. The SDK needs transpiled JS to properly be able to do transformations to modules. We could transpile the user code ourselves but that is fragile AF - so not an option.

As of now, the SDK will continue to work in production mode which is arguably more important, but we would like to support dev mode.

Branch with my experiments: #9295

To clarify, does it work with Turbopack in production mode as-is or only with the changes in your branch?

[lforst]

@Stanzilla Turbopack will not work with the SDK (dev and prod). My branch does not contain any fixes or features, just experiments proving that things don't work.

[leerob]

It's also worth noting that the initial Turbopack support is for next dev, which is only for your local environment. next build support will come later 🙏

[r34son]

Thanks for sharing the link for the fix. As fas as I know, this should also work with an override. In pnpm it's not a key at the root of the package.json. You have to wrap it with the key "pnpm" like this:

 "pnpm": {
    "overrides": {
       "import-in-the-middle": "1.11.2"
    }
  }

And just for context: In npm it's overrides as well, but on the root-level.

Overrides doesn't hoist packages to the root level of node_modules. How can it fix the issue?

[stevejcox]

Curious if this is on a roadmap, we'd really like to see this implemented.

[MisterJimson]

@r34son I found that a .npmrc with the following worked for me for pnpm.

public-hoist-pattern[]=*import-in-the-middle*
public-hoist-pattern[]=*require-in-the-middle*

[r34son]

@r34son I found that a .npmrc with the following worked for me for pnpm.

public-hoist-pattern[]=*import-in-the-middle*
public-hoist-pattern[]=*require-in-the-middle*

Exactly like i mentioned here vercel/next.js#68805 (comment)

[jlvdh]

For people looking to use turbo locally you can only use withSentryConfig when building.

/** @type {import('next').NextConfig} */
let nextConfig = {}

if (process.env.NODE_ENV === 'production') {
const { withSentryConfig } = await import('@sentry/nextjs')
nextConfig = withSentryConfig(nextConfig, {})
}

export default nextConfig

This unfortunately still gave a lot of errors for us as we imported the sentry package for captureException on other places. We fixed it by mocking Sentry for turbopack builds:

  experimental: {
    turbo: {
      resolveAlias: {
        "@sentry/nextjs": "./src/mocks/sentry-mock.ts",
      },
    },
  },

[calvinf]

Per areweturboyet.com, production Next.js support for Turbopack is currently (as of Feb. 27, 2025) at 98.3%.

7760 of 7895 next build tests passing (135 left for 100%)

This will get more urgent when Next fully lights up production support for Turbopack.

[lforst]

@calvinf, we are in talks with Vercel, and this is being actively worked on. We need Next.js to ship a few features for us to be able to support turbopack. Stay tuned.