fix(nextjs): Skip re instrumentating on generate phase of experimental build mode

[RulaKhaled]

Next.js v15.3.0-canary.1 introduced a new approach to the two-phase experimental build (--experimental-build-mode=compile then =generate) that applies env inlining during generate build mode.

Why it breaks?
Our withSentryConfig still assumes a single “full” build and reruns its Webpack instrumentation in both phases. During the generate step it collides with Next.js’s new inliner (e.g. for assetPrefix), producing malformed JS and build failures.

Root cause: Double application of build-time transforms—Sentry inlines/reprocesses a bundle that Next.js’s generate mode is simultaneously trying to finalize—leads to conflicting replacements and syntax errors.

This PR is a quick workaround that patches our build script so that:

1. Compile phase (--experimental-build-mode=compile): Sentry’s instrumentation runs as usual.
2. Generate phase (--experimental-build-mode=generate): We skip Sentry’s build-time hooks entirely, letting Next.js handle inlining and prerendering without collision.

This immediately prevents the build failures and defers full “generate” work to Next.js’s own pipeline. I confirmed that source maps and error / tracing still function as expected, BUT things might still occur as it's still an experimental undocumented feature.

[AbhiPrasad]

I would like us to expand this comment to be more specific to what we don't support, or link to a docs page that explains this in more detail.

[RulaKhaled]

I can write something up in the docs and link it here when it's ready; yet i'm not sure how useful it'll be for users. Source maps, tracing, and error handling work as expected for now, but since we inline things differently at compile time than what Next.js does, some issues might still come up and it's just good to flag -if something breaks- that this isn't a fully robust solution.

[AbhiPrasad]

Having something there is useful because we can add items to it as it comes up, even if nothing is too important atm.

[RulaKhaled]

makes sense, will add it to the docs! Is this a blocker for this PR though?

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[victorandree]

I found this PR from having seen the warning in my build logs. It reads scary, with little more information to go on... I appreciate that this is an experimental setting of Next.js, but speaking as a user, I'd love to read a bit more about this in the Sentry docs. :)

You are generally pretty good at explaining the status of support for upcoming and experimental features (e.g. Turbopack).

Ping @RulaKhaled

[RulaKhaled]

Next.js v15.3.0-canary.1 introduced a new approach to the two-phase experimental build (--experimental-build-mode=compile then =generate) that applies env inlining during generate build mode.

Why it breaks?
Our withSentryConfig still assumes a single “full” build and reruns its Webpack instrumentation in both phases. During the generate step it collides with Next.js’s new inliner (e.g. for assetPrefix), producing malformed JS and build failures.

Root cause: Double application of build-time transforms—Sentry inlines/reprocesses a bundle that Next.js’s generate mode is simultaneously trying to finalize—leads to conflicting replacements and syntax errors.

This PR is a quick workaround that patches our build script so that:

1. Compile phase (--experimental-build-mode=compile): Sentry’s instrumentation runs as usual.
2. Generate phase (--experimental-build-mode=generate): We skip Sentry’s build-time hooks entirely, letting Next.js handle inlining and prerendering without collision.

This immediately prevents the build failures and defers full “generate” work to Next.js’s own pipeline. I confirmed that source maps and error / tracing still function as expected, BUT things might still occur as it's still an experimental undocumented feature.

[AbhiPrasad]

I would like us to expand this comment to be more specific to what we don't support, or link to a docs page that explains this in more detail.

[RulaKhaled]

I can write something up in the docs and link it here when it's ready; yet i'm not sure how useful it'll be for users. Source maps, tracing, and error handling work as expected for now, but since we inline things differently at compile time than what Next.js does, some issues might still come up and it's just good to flag -if something breaks- that this isn't a fully robust solution.

[AbhiPrasad]

Having something there is useful because we can add items to it as it comes up, even if nothing is too important atm.

[RulaKhaled]

makes sense, will add it to the docs! Is this a blocker for this PR though?

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[victorandree]

I found this PR from having seen the warning in my build logs. It reads scary, with little more information to go on... I appreciate that this is an experimental setting of Next.js, but speaking as a user, I'd love to read a bit more about this in the Sentry docs. :)

You are generally pretty good at explaining the status of support for upcoming and experimental features (e.g. Turbopack).

Ping @RulaKhaled

[RulaKhaled]

Next.js v15.3.0-canary.1 introduced a new approach to the two-phase experimental build (--experimental-build-mode=compile then =generate) that applies env inlining during generate build mode.

Why it breaks?
Our withSentryConfig still assumes a single “full” build and reruns its Webpack instrumentation in both phases. During the generate step it collides with Next.js’s new inliner (e.g. for assetPrefix), producing malformed JS and build failures.

Root cause: Double application of build-time transforms—Sentry inlines/reprocesses a bundle that Next.js’s generate mode is simultaneously trying to finalize—leads to conflicting replacements and syntax errors.

This PR is a quick workaround that patches our build script so that:

1. Compile phase (--experimental-build-mode=compile): Sentry’s instrumentation runs as usual.
2. Generate phase (--experimental-build-mode=generate): We skip Sentry’s build-time hooks entirely, letting Next.js handle inlining and prerendering without collision.

This immediately prevents the build failures and defers full “generate” work to Next.js’s own pipeline. I confirmed that source maps and error / tracing still function as expected, BUT things might still occur as it's still an experimental undocumented feature.

[AbhiPrasad]

I would like us to expand this comment to be more specific to what we don't support, or link to a docs page that explains this in more detail.

[RulaKhaled]

I can write something up in the docs and link it here when it's ready; yet i'm not sure how useful it'll be for users. Source maps, tracing, and error handling work as expected for now, but since we inline things differently at compile time than what Next.js does, some issues might still come up and it's just good to flag -if something breaks- that this isn't a fully robust solution.

[AbhiPrasad]

Having something there is useful because we can add items to it as it comes up, even if nothing is too important atm.

[RulaKhaled]

makes sense, will add it to the docs! Is this a blocker for this PR though?

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[victorandree]

I found this PR from having seen the warning in my build logs. It reads scary, with little more information to go on... I appreciate that this is an experimental setting of Next.js, but speaking as a user, I'd love to read a bit more about this in the Sentry docs. :)

You are generally pretty good at explaining the status of support for upcoming and experimental features (e.g. Turbopack).

Ping @RulaKhaled

[RulaKhaled]

Next.js v15.3.0-canary.1 introduced a new approach to the two-phase experimental build (--experimental-build-mode=compile then =generate) that applies env inlining during generate build mode.

Why it breaks?
Our withSentryConfig still assumes a single “full” build and reruns its Webpack instrumentation in both phases. During the generate step it collides with Next.js’s new inliner (e.g. for assetPrefix), producing malformed JS and build failures.

Root cause: Double application of build-time transforms—Sentry inlines/reprocesses a bundle that Next.js’s generate mode is simultaneously trying to finalize—leads to conflicting replacements and syntax errors.

This PR is a quick workaround that patches our build script so that:

1. Compile phase (--experimental-build-mode=compile): Sentry’s instrumentation runs as usual.
2. Generate phase (--experimental-build-mode=generate): We skip Sentry’s build-time hooks entirely, letting Next.js handle inlining and prerendering without collision.

This immediately prevents the build failures and defers full “generate” work to Next.js’s own pipeline. I confirmed that source maps and error / tracing still function as expected, BUT things might still occur as it's still an experimental undocumented feature.

[AbhiPrasad]

I would like us to expand this comment to be more specific to what we don't support, or link to a docs page that explains this in more detail.

[RulaKhaled]

I can write something up in the docs and link it here when it's ready; yet i'm not sure how useful it'll be for users. Source maps, tracing, and error handling work as expected for now, but since we inline things differently at compile time than what Next.js does, some issues might still come up and it's just good to flag -if something breaks- that this isn't a fully robust solution.

[AbhiPrasad]

Having something there is useful because we can add items to it as it comes up, even if nothing is too important atm.

[RulaKhaled]

makes sense, will add it to the docs! Is this a blocker for this PR though?

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[victorandree]

I found this PR from having seen the warning in my build logs. It reads scary, with little more information to go on... I appreciate that this is an experimental setting of Next.js, but speaking as a user, I'd love to read a bit more about this in the Sentry docs. :)

You are generally pretty good at explaining the status of support for upcoming and experimental features (e.g. Turbopack).

Ping @RulaKhaled

[RulaKhaled]

Next.js v15.3.0-canary.1 introduced a new approach to the two-phase experimental build (--experimental-build-mode=compile then =generate) that applies env inlining during generate build mode.

Why it breaks?
Our withSentryConfig still assumes a single “full” build and reruns its Webpack instrumentation in both phases. During the generate step it collides with Next.js’s new inliner (e.g. for assetPrefix), producing malformed JS and build failures.

Root cause: Double application of build-time transforms—Sentry inlines/reprocesses a bundle that Next.js’s generate mode is simultaneously trying to finalize—leads to conflicting replacements and syntax errors.

This PR is a quick workaround that patches our build script so that:

1. Compile phase (--experimental-build-mode=compile): Sentry’s instrumentation runs as usual.
2. Generate phase (--experimental-build-mode=generate): We skip Sentry’s build-time hooks entirely, letting Next.js handle inlining and prerendering without collision.

This immediately prevents the build failures and defers full “generate” work to Next.js’s own pipeline. I confirmed that source maps and error / tracing still function as expected, BUT things might still occur as it's still an experimental undocumented feature.

[AbhiPrasad]

I would like us to expand this comment to be more specific to what we don't support, or link to a docs page that explains this in more detail.

[RulaKhaled]

I can write something up in the docs and link it here when it's ready; yet i'm not sure how useful it'll be for users. Source maps, tracing, and error handling work as expected for now, but since we inline things differently at compile time than what Next.js does, some issues might still come up and it's just good to flag -if something breaks- that this isn't a fully robust solution.

[AbhiPrasad]

Having something there is useful because we can add items to it as it comes up, even if nothing is too important atm.

[RulaKhaled]

makes sense, will add it to the docs! Is this a blocker for this PR though?

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[victorandree]

I found this PR from having seen the warning in my build logs. It reads scary, with little more information to go on... I appreciate that this is an experimental setting of Next.js, but speaking as a user, I'd love to read a bit more about this in the Sentry docs. :)

You are generally pretty good at explaining the status of support for upcoming and experimental features (e.g. Turbopack).

Ping @RulaKhaled

[RulaKhaled]

Next.js v15.3.0-canary.1 introduced a new approach to the two-phase experimental build (--experimental-build-mode=compile then =generate) that applies env inlining during generate build mode.

Why it breaks?
Our withSentryConfig still assumes a single “full” build and reruns its Webpack instrumentation in both phases. During the generate step it collides with Next.js’s new inliner (e.g. for assetPrefix), producing malformed JS and build failures.

Root cause: Double application of build-time transforms—Sentry inlines/reprocesses a bundle that Next.js’s generate mode is simultaneously trying to finalize—leads to conflicting replacements and syntax errors.

This PR is a quick workaround that patches our build script so that:

1. Compile phase (--experimental-build-mode=compile): Sentry’s instrumentation runs as usual.
2. Generate phase (--experimental-build-mode=generate): We skip Sentry’s build-time hooks entirely, letting Next.js handle inlining and prerendering without collision.

This immediately prevents the build failures and defers full “generate” work to Next.js’s own pipeline. I confirmed that source maps and error / tracing still function as expected, BUT things might still occur as it's still an experimental undocumented feature.

[AbhiPrasad]

I would like us to expand this comment to be more specific to what we don't support, or link to a docs page that explains this in more detail.

[RulaKhaled]

I can write something up in the docs and link it here when it's ready; yet i'm not sure how useful it'll be for users. Source maps, tracing, and error handling work as expected for now, but since we inline things differently at compile time than what Next.js does, some issues might still come up and it's just good to flag -if something breaks- that this isn't a fully robust solution.

[AbhiPrasad]

Having something there is useful because we can add items to it as it comes up, even if nothing is too important atm.

[RulaKhaled]

makes sense, will add it to the docs! Is this a blocker for this PR though?

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[victorandree]

I found this PR from having seen the warning in my build logs. It reads scary, with little more information to go on... I appreciate that this is an experimental setting of Next.js, but speaking as a user, I'd love to read a bit more about this in the Sentry docs. :)

You are generally pretty good at explaining the status of support for upcoming and experimental features (e.g. Turbopack).

Ping @RulaKhaled

[RulaKhaled]

Next.js v15.3.0-canary.1 introduced a new approach to the two-phase experimental build (--experimental-build-mode=compile then =generate) that applies env inlining during generate build mode.

Why it breaks?
Our withSentryConfig still assumes a single “full” build and reruns its Webpack instrumentation in both phases. During the generate step it collides with Next.js’s new inliner (e.g. for assetPrefix), producing malformed JS and build failures.

Root cause: Double application of build-time transforms—Sentry inlines/reprocesses a bundle that Next.js’s generate mode is simultaneously trying to finalize—leads to conflicting replacements and syntax errors.

This PR is a quick workaround that patches our build script so that:

1. Compile phase (--experimental-build-mode=compile): Sentry’s instrumentation runs as usual.
2. Generate phase (--experimental-build-mode=generate): We skip Sentry’s build-time hooks entirely, letting Next.js handle inlining and prerendering without collision.

This immediately prevents the build failures and defers full “generate” work to Next.js’s own pipeline. I confirmed that source maps and error / tracing still function as expected, BUT things might still occur as it's still an experimental undocumented feature.

[AbhiPrasad]

I would like us to expand this comment to be more specific to what we don't support, or link to a docs page that explains this in more detail.

[RulaKhaled]

I can write something up in the docs and link it here when it's ready; yet i'm not sure how useful it'll be for users. Source maps, tracing, and error handling work as expected for now, but since we inline things differently at compile time than what Next.js does, some issues might still come up and it's just good to flag -if something breaks- that this isn't a fully robust solution.

[AbhiPrasad]

Having something there is useful because we can add items to it as it comes up, even if nothing is too important atm.

[RulaKhaled]

makes sense, will add it to the docs! Is this a blocker for this PR though?

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[victorandree]

I found this PR from having seen the warning in my build logs. It reads scary, with little more information to go on... I appreciate that this is an experimental setting of Next.js, but speaking as a user, I'd love to read a bit more about this in the Sentry docs. :)

You are generally pretty good at explaining the status of support for upcoming and experimental features (e.g. Turbopack).

Ping @RulaKhaled

[RulaKhaled]

Next.js v15.3.0-canary.1 introduced a new approach to the two-phase experimental build (--experimental-build-mode=compile then =generate) that applies env inlining during generate build mode.

Why it breaks?
Our withSentryConfig still assumes a single “full” build and reruns its Webpack instrumentation in both phases. During the generate step it collides with Next.js’s new inliner (e.g. for assetPrefix), producing malformed JS and build failures.

Root cause: Double application of build-time transforms—Sentry inlines/reprocesses a bundle that Next.js’s generate mode is simultaneously trying to finalize—leads to conflicting replacements and syntax errors.

This PR is a quick workaround that patches our build script so that:

1. Compile phase (--experimental-build-mode=compile): Sentry’s instrumentation runs as usual.
2. Generate phase (--experimental-build-mode=generate): We skip Sentry’s build-time hooks entirely, letting Next.js handle inlining and prerendering without collision.

This immediately prevents the build failures and defers full “generate” work to Next.js’s own pipeline. I confirmed that source maps and error / tracing still function as expected, BUT things might still occur as it's still an experimental undocumented feature.

[AbhiPrasad]

I would like us to expand this comment to be more specific to what we don't support, or link to a docs page that explains this in more detail.

[RulaKhaled]

I can write something up in the docs and link it here when it's ready; yet i'm not sure how useful it'll be for users. Source maps, tracing, and error handling work as expected for now, but since we inline things differently at compile time than what Next.js does, some issues might still come up and it's just good to flag -if something breaks- that this isn't a fully robust solution.

[AbhiPrasad]

Having something there is useful because we can add items to it as it comes up, even if nothing is too important atm.

[RulaKhaled]

makes sense, will add it to the docs! Is this a blocker for this PR though?

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[AbhiPrasad]

not a PR blocker, we can do it as a follow up

[victorandree]

I found this PR from having seen the warning in my build logs. It reads scary, with little more information to go on... I appreciate that this is an experimental setting of Next.js, but speaking as a user, I'd love to read a bit more about this in the Sentry docs. :)

You are generally pretty good at explaining the status of support for upcoming and experimental features (e.g. Turbopack).

Ping @RulaKhaled