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 🙏

[lforst]

At this point, Sentry is the only tool holding back the full migration to turbo. Do you have any particular tasks I could pick up to help the situation?

@yordis The brunt of the work needs to be implemented in Next.js

• The highest priority is an equivalent or extension of instrumentation.ts for the clientside. Currently, we do this via webpack entry points.
• A hook in Turbopack/Next.js that we can use to upload source maps (ie. something like onBuildEnd)

Also, I want to reiterate: You should be able to run Turbopack in dev in combination with Sentry without any issues. Nothing should break. Unless you want to monitor your dev environment, everything should be good. Turbo is not stable for prod builds yet.

[pppdns]

thank you for the reply.

Is the Sentry team going to submit these feature PR-s to the open source Next.js repo?

If not, does the Next.js team know about this requirement and do you know whether this is on their roadmap at all?

[chargome]

@pppdns there is vercel/next.js#69294

[lforst]

@pppdns

Is the Sentry team going to submit these feature PR-s to the open source Next.js repo?

Likely not. These tasks require expert knowledge and have some nuance that the Next.js team needs to figure out and align with their goals. Simply submitting a PR likely aint gonna cut it because it first requires discussion.

If not, does the Next.js team know about this requirement and do you know whether this is on their roadmap at all?

They know about it. I don't know their current roadmap.

[r34son]

@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"
  },

Do not work for pnpm. Waiting for fix in vercel/next.js#68805

[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"
  },

Do not work for pnpm. Waiting for fix in vercel/next.js#68805

@r34son I think for pnpm you can use overrides: https://pnpm.io/package_json#pnpmoverrides

[r34son]

@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"
  },

Do not work for pnpm. Waiting for fix in vercel/next.js#68805

@r34son I think for pnpm you can use overrides: https://pnpm.io/package_json#pnpmoverrides

Nope, overrides doesn't solve the issue. I posted fix for pnpm here vercel/next.js#68805 (comment)

[s1gr1d]

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.

[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?