Slow build-times and Webpack serialization performance warnings when using @sentry/nextjs

[scobbe]

⚠️ Edit by @lforst: This issue is confirmed. Please see #15100 (comment) for more information on why builds are slow when adding the Sentry SDK, and for temporary workarounds until performance issues are fixed within the SDK.

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nestjs

SDK Version

8.50.0

Framework Version

React 19.0.0, Next 15.1.4, Node 22.9.0

Link to Sentry event

No response

Reproduction Example/SDK Setup

Description

When adding Sentry configuration to next.config.ts using withSentryConfig, I encounter the following warning during the build process:

<w> [webpack.cache.PackFileCacheStrategy] Serializing big strings (318kiB) impacts deserialization performance (consider using Buffer instead and decode when needed)

Is this a known issue? Are there any recommendations for addressing this warning, such as additional configuration options or workarounds?

Thank you!

Steps to Reproduce

1. Start with a minimal next.config.ts file:

   import type { NextConfig } from "next";
   
   const nextConfig: NextConfig = {};
   
   export default nextConfig;

2. Update the file to include Sentry's configuration using withSentryConfig:

   import type { NextConfig } from "next";
   
   import { withSentryConfig } from "@sentry/nextjs";
   
   const nextConfig: NextConfig = {};
   
   export default withSentryConfig(nextConfig, {
     automaticVercelMonitors: true,
     disableLogger: true,
     hideSourceMaps: true,
     org: "MyOrg",
     project: "javascript-nextjs",
     reactComponentAnnotation: {
       enabled: true,
     },
     silent: !process.env.CI,
     sourcemaps: {
       deleteSourcemapsAfterUpload: true,
       disable: process.env.NODE_ENV === "development",
     },
     tunnelRoute: "/monitoring",
     widenClientFileUpload: true,
   });

3. Run the build process.

Expected Result

The build completes without warnings or errors.

Actual Result

The following warning appears during the build process:

<w> [webpack.cache.PackFileCacheStrategy] Serializing big strings (318kiB) impacts deserialization performance (consider using Buffer instead and decode when needed)

[andreiborza]

Hello @scobbe, thank you for filing this.

Could you please provide a reproduction repo? I tried setting up a new nextjs project using npx create-next-app@latest and setting Sentry up using npx @sentry/wizard@latest -i nextjs but did not run into any such warnings.

[kimdanielarthur-cowlabs]

same issue here with same env , however do not have reproduction repo sadly

[aaa3334]

Same issue here. Only happened when I added sentry in and the build (running npm run dev) now takes a LOT longer.

Versions:

"@sentry/nextjs": "^8.51.0",
"next": "14.2.16",

[Lms24]

We still need a reproduction for this to investigate further. Thanks!

[MonstraG]

I finally reproduced it!

https://github.com/MonstraG/sentry-webpack-strings-bug

1. Before trying anything, make sure to remove .next folder. Repeated build attempts make the warning go away sometimes
2. ALL of the following are required for the issue to occur:

• sentry is set up (instrumentation.ts, sentry.client.config.ts and withSentryConfig in next.config)
• middleware.ts is present (even completely empty file)
• (sic!) app router folder is not in src/app but directly in the root of the project. (see last commit in repro)

[markedwards]

Just to clarify -- is the webpack.cache.PackFileCacheStrategy a problem, regardless of whether it impacts build times? Will it be fixed?

[lforst]

@markedwards as pointed out in #15100 (comment), it is very likely not a problem, not contributing to build times in any significant way, and will therefore likely not be fixed (also because I wouldn't know how). It will very likely implicitly get fixed with Trubopack.

[MonstraG]

Hello, we have rule against using any, so this doesn't fly for us:

export const onRequestError = async (...args: [any, any, any]) => {
  if (process.env.NODE_ENV === "production") {
    captureRequestError(...args);
  }
};

Actual types are [unknown, RequestInfo, ErrorContext] but they are defined near captureRequestError and not exported, so we have to copy-paste them. Can they be exported please?

[sengirab]

Hello, we have rule against using any, so this doesn't fly for us:

export const onRequestError = async (...args: [any, any, any]) => {
if (process.env.NODE_ENV === "production") {
captureRequestError(...args);
}
};
Actual types are [unknown, RequestInfo, ErrorContext] but they are defined near captureRequestError and not exported, so we have to copy-paste them. Can they be exported please?

I mean, you could just not type it? Or type it as unknown?

[MonstraG]

I mean, you could just not type it? Or type it as unknown?

No, because the sentry's function /does/ use these types. If 3 unknowns are used, it produces:

TS2345: Argument of type unknown is not assignable to parameter of type RequestInfo
Type {} is missing the following properties from type RequestInfo: path, method, header

If I remove the types, it's implicitly any[] and errors with TS7019.

I could also probably come up with something like Parameters<typeof captureRequestError>[0], Parameters<typeof captureRequestError>[1]... but that's kind of annoying also

[mxseev]

The recommendations don't help, disabling the Sentry plugin in Next config causes spamming errors to the console. But I think I found a solution: completely replace the @sentry/nextjs package with a mock implementation using webpack.resolve.alias:

next.config.ts

import type { NextConfig } from "next"
import { type SentryBuildOptions, withSentryConfig } from "@sentry/nextjs"

const isProd = process.env.NODE_ENV === "production"

const nextConfig: NextConfig = {
  webpack: (config, { webpack, isServer }) => {
    // see the lib/sentry-dev.ts file to see what's going on here and why.
    if (!isProd) {
      config.resolve = {
        ...config.resolve,
        alias: {
          ...config.resolve.alias,
          "@sentry/nextjs": "@/lib/sentry-dev",
        },
      }
    }

    return config
  },
}

const sentryConfig: SentryBuildOptions = {
}

const composedConfig = isProd
  ? withSentryConfig(nextConfig, sentryConfig)
  : nextConfig

export default composedConfig

src/lib/sentry-dev.ts

// this file contains fake implementation of all used functions from sentry
// and they will be used in local development

// @sentry/nextjs has a big problem with local development
// build time (including HMR) increases about 2-3 times
// see https://github.com/getsentry/sentry-javascript/issues/15100

// Just disabling the sentry plugin in the Next config
// breaks the build completely when trying to import sentry package

// with webpack.resolve.alias, this file will be imported
// instead of the "@sentry/nextjs" package

// set true for forward Sentry calls to console
const dump = false

const wrapper =
  (name: string, fn: typeof console.log) =>
  (...args) => {
    if (dump) fn(`SentryDevFake.${name}`, ...args)
  }

export const init = wrapper("init", console.info)
export const captureException = wrapper("captureException", console.error)
export const setUser = wrapper("setUser", console.info)

export const browserTracingIntegration = wrapper("browserTracingIntegration", console.info)
export const browserProfilingIntegration = wrapper("browserProfilingIntegration", console.info)
export const httpClientIntegration = wrapper("httpClientIntegration", console.info)

export const startSpan = (options, callback) => {
  wrapper("startSpan", console.info)(options)

  return callback()
}

export const withServerActionInstrumentation = (name, options, next) => {
  wrapper("withServerActionInstrumentation", console.info)(name, options)

  return next()
}

(don't forget to mock all used functions from Sentry that you use in the project)

---

Yes, it's not pretty and hacky, but waiting tens of seconds to rebuild a simple changes is even worse

[lforst]

@mxseev not calling withSentryConfig should not break your builds.

[alexeyshurygin]

What helped me to cut build time from 1:44 to 0:36 is commenting addition of SentryConfig altogether (in development env) in next.config.ts. I use bun. So it is time for bun run build.
// export default withSentryConfig(nextConfig, { next": "^15.2.4
@sentry/nextjs": "^9.9.0
HTH