fix(nextjs): Pull transpileClientSDK option from correct location (#…

…5516)

In the process of working simultaneously on both #5472 (which adds the `sentry.transpileClientSDK` option to `next.config.js`) and #5473 (which moves the `sentry` options object from `next.config.js` to a new location halfway through the build process, in order to prevent nextjs from throwing warnings), I missed their overlap. As a result, the `transpileClientSDK` option is still currently being retrieved from the old, pre-move location, even though said retrieval happens in the second half of the build, after the move. (Unsurprisingly, it's therefore always undefined, rendering it useless).

This fixes that by pulling it from the new, correct location instead. It also adjusts our types so that future mistakes like this will show up as errors, by creating separate pre-move and post-move `userNextConfig` types and using them as appropriate.

Fixes #5452.

packages/nextjs/src/config/index.ts

@@ -16,13 +16,15 @@ export function withSentryConfig(
   // `defaults` in order to pass them along to the user's function
   if (typeof exportedUserNextConfig === 'function') {
     return function (phase: string, defaults: { defaultConfig: NextConfigObject }): NextConfigObject {
-      const userNextConfigObject = exportedUserNextConfig(phase, defaults);
+      let userNextConfigObject = exportedUserNextConfig(phase, defaults);
 
       // Next 12.2.3+ warns about non-canonical properties on `userNextConfig`, so grab and then remove the `sentry`
       // property there. Where we actually need it is in the webpack config function we're going to create, so pass it
       // to `constructWebpackConfigFunction` so that it will be in the created function's closure.
       const { sentry: userSentryOptions } = userNextConfigObject;
       delete userNextConfigObject.sentry;
+      // Remind TS that there's now no `sentry` property
+      userNextConfigObject = userNextConfigObject as NextConfigObject;
 
       return {
         ...userNextConfigObject,
@@ -41,9 +43,11 @@ export function withSentryConfig(
   // for a more thorough explanation of what we're doing here.)
   const { sentry: userSentryOptions } = exportedUserNextConfig;
   delete exportedUserNextConfig.sentry;
+  // Remind TS that there's now no `sentry` property
+  const userNextConfigObject = exportedUserNextConfig as NextConfigObject;
 
   return {
-    ...exportedUserNextConfig,
-    webpack: constructWebpackConfigFunction(exportedUserNextConfig, userSentryWebpackPluginOptions, userSentryOptions),
+    ...userNextConfigObject,
+    webpack: constructWebpackConfigFunction(userNextConfigObject, userSentryWebpackPluginOptions, userSentryOptions),
   };
 }

packages/nextjs/src/config/types.ts

@@ -8,7 +8,18 @@ export type SentryWebpackPlugin = WebpackPluginInstance & { options: SentryWebpa
  * Overall Nextjs config
  */
 
-export type ExportedNextConfig = NextConfigObject | NextConfigFunction;
+// The first argument to `withSentryConfig` (which is the user's next config) may contain a `sentry` key, which we'll
+// remove once we've captured it, in order to prevent nextjs from throwing warnings. Since it's only in there
+// temporarily, we don't include it in the main `NextConfigObject` or `NextConfigFunction` types.
+export type ExportedNextConfig = NextConfigObjectWithSentry | NextConfigFunctionWithSentry;
+
+export type NextConfigObjectWithSentry = NextConfigObject & {
+  sentry?: UserSentryOptions;
+};
+export type NextConfigFunctionWithSentry = (
+  phase: string,
+  defaults: { defaultConfig: NextConfigObject },
+) => NextConfigObjectWithSentry;
 
 export type NextConfigObject = {
   // custom webpack options
@@ -21,7 +32,6 @@ export type NextConfigObject = {
   basePath?: string;
   // config which will be available at runtime
   publicRuntimeConfig?: { [key: string]: unknown };
-  sentry?: UserSentryOptions;
 };
 
 export type UserSentryOptions = {

packages/nextjs/src/config/webpack.ts

@@ -80,7 +80,7 @@ export function constructWebpackConfigFunction(
     // who want to support such browsers, `transpileClientSDK` allows them to force the SDK code to go through the same
     // transpilation that their code goes through. We don't turn this on by default because it increases bundle size
     // fairly massively.
-    if (!isServer && userNextConfig.sentry?.transpileClientSDK) {
+    if (!isServer && userSentryOptions?.transpileClientSDK) {
       // Find all loaders which apply transpilation to user code
       const transpilationRules = findTranspilationRules(newConfig.module?.rules, projectDir);