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. https://github.com/unjs/unplugin/issues/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

https://github.com/unjs/unplugin/issues/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 🙏

[lforst]

I would love to get rid of the Sentry SDK's dependency on build tooling (i.e. Webpack and Turbopack) entirely. The reason we need to rely on Webpack at the moment is that Next.js lacks options to instrument Next.js apps. Webpack was the next entry point higher up in the chain of abstraction that allowed the SDK to do the stuff it needed to do.

Newer versions of Next.js already have the instrumentation.ts hook and OTEL support. This is very good. The only thing we lack now is a central hook that reports all errors inside a Next.js application (with metadata (!), eg. what route the error was thrown in).

We will do our best to support Turbopack when it becomes relevant. However, upstream changes are needed. I do not believe Sentry is the only player that would profit from this.

[fromthemills]

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

[lforst]

I think we are slowly moving into a world where we can think about getting rid of all of our reliance on webpack. These are the following features we use it for:

• Various variable injection
  • This can probably be resolved by using process.env.NEXT_PUBLIC_ constants .
• Wrapping of various server functionalities
  • Error reporting can be replaced by new onRequestError hook
  • Performance reporting can be outsourced to Next.js OTEL instrumentation
• sentry.client.config.ts injection
  • TBD
• Error reporting of pages router pages render errors
  • TBD
• Sourcemap upload
  • TBD
• React component annotations
  • TBD

[lforst]

The following is the master plan to support Turbopack in dev mode to a degree that is "workable".

• [ ] (dependent on Vercel/Next.js team) Add something like the instrumentation.ts hook to the client which also exposes errors that happen during rendering (relevant discussion: https://github.com/vercel/next.js/discussions/69294)
• [ ] (dependent on Vercel/Next.js team) Find a way to inject build-time constants into the various bundles (relevant discussion: https://github.com/vercel/next.js/discussions/71476) - PR: https://github.com/vercel/next.js/pull/71802
• [x] (dependent on Vercel/Next.js team) Contribute propagating the client trace metadata to the client in the pages router (https://github.com/vercel/next.js/pull/69620)
• [x] Stabilize and document experimental_captureRequestError and add to wizard
• [x] Make edge SDK OTEL ready
• [x] Switch the SDK to completely rely on Next.js' OTEL instrumentation (apart from central data cleanup) so that we do not need the build for performance instrumentation any longer (https://github.com/getsentry/sentry-javascript/pull/13889)

---

Stuff that wouldn't be supported in Turbopack dev mode due to the lack of a plugin system in Turbopack:

• All kinds of build time sweetness like React component annotations, module metadata (MFE support), bundle size optimizations, application key (filtering 3rd party errors)
• Sourcemap uploading but that is undesired with dev mode in any case.

[guhur]

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

It become stable now at the beginning of the month. Would love to integrate it with sentry now :-)

[lforst]

@guhur We are actively working on it. Tubopack may be stable but it still doesn't support a lot of features the SDK needs. You can use turbopack at any time with Sentry. Sentry just won't work well in dev mode. Turbopack for prod builds is still not stable.

[TheCukitoDev]

Hello, i got an error while running just pnpm dev --turbo on Next.js 15 with Sentry. This is the error:

⚠ ./node_modules/.pnpm/@sentry+node@8.35.0/node_modules/@sentry/node/build/cjs/sdk
Package import-in-the-middle can't be external
The request import-in-the-middle matches serverExternalPackages (or the default list).
The request could not be resolved by Node.js from the project directory.
Packages that should be external need to be installed in the project directory, so they can be resolved from the output files.
Try to install it into the project directory by running npm install import-in-the-middle from the project directory.

I did pnpm add import-in-the-middle to install the package but it doesen't makes anything

EDIT: It don't make any compiling error but i think it should not be there

[spyl94]

@TheCukitoDev I have fixed this issue by adding serverExternalPackages: ['@sentry/node', '@sentry/nextjs'] in my next.config.js

[lforst]

@spyl94 @TheCukitoDev please don't externalize the SDK. That will break it in all kinds of ways potentially. Instead add an override for your package manager to only have one import-in-the-middle package version in your dependencies. In theory Next.js shouldn't crash though.

[TheCukitoDev]

It is my mistake sorry. I added require-in-the-middle instead of import-in-the-middle but I thought it was what it tells me the error to. Sorry.

[TheCukitoDev]

Again Sorry. I made a mistake. When using react 18 it needs to use import-in-the-middle but when using the actual RC of React that next supports it needs require-in-the-middle so it is the confussion. Sorry again but I think now is clear and anyone with the same issue can solve it.

[Rednegniw]

Again Sorry. I made a mistake. When using react 18 it needs to use import-in-the-middle but when using the actual RC of React that next supports it needs require-in-the-middle so it is the confussion. Sorry again but I think now is clear and anyone with the same issue can solve it.

Could you please explain how you solved this? Did the error stop showing? 🙏

[lforst]

@Rednegniw It depends a bit on your package manager but it is solved by adding a resolution to your package.json. This is for yarn:

  "resolutions": {
    "import-in-the-middle": "1.11.2"
  },

[pppdns]

Any news on this?

[chargome]

@pppdns we still depend on some upstream changes for client-side instrumentation. For the server-side we're already picking up otel data from Next.js. Note that this only affects your devserver, Sentry will work as expected in your production build. We'll be posting any updates regarding turbopack here.