fix(nextjs): preserve existing conditionNames when adding development

Only prepend 'development' to existing conditionNames if they exist,
preserving Next.js's original ESM/CJS resolution behavior. This avoids
the 'export *' client boundary error while still enabling SDK development
features like Spotlight auto-enablement.

Author: BYK

dev-packages/e2e-tests/test-applications/nextjs-15-spotlight/next.config.js

@@ -7,20 +7,6 @@ const nextConfig = {
   env: {
     NEXT_PUBLIC_SENTRY_SPOTLIGHT: 'true',
   },
-
-  // Configure webpack to use 'development' export condition in dev mode
-  // This enables Sentry SDK's development-only features like Spotlight auto-enablement
-  // Note: This is required because Next.js doesn't use the 'development' condition by default
-  webpack: (config, { dev }) => {
-    if (dev) {
-      config.resolve = config.resolve || {};
-      config.resolve.conditionNames = [
-        'development',
-        ...(config.resolve.conditionNames || ['import', 'module', 'browser', 'require', 'node', 'default']),
-      ];
-    }
-    return config;
-  },
 };
 
 module.exports = withSentryConfig(nextConfig, {

packages/nextjs/src/config/webpack.ts

@@ -97,6 +97,13 @@ export function constructWebpackConfigFunction({
     // `newConfig.module.rules` is required, so we don't have to keep asserting its existence
     const newConfig = setUpModuleRules(rawNewConfig);
 
+    // In development mode, add 'development' to resolve conditions so that
+    // @sentry/* packages use their development exports (which include features like Spotlight auto-enablement)
+    // We only prepend 'development' to existing conditions to preserve Next.js's ESM/CJS resolution behavior
+    if (isDev && newConfig.resolve?.conditionNames && !newConfig.resolve.conditionNames.includes('development')) {
+      newConfig.resolve.conditionNames = ['development', ...newConfig.resolve.conditionNames];
+    }
+
     // Add a loader which will inject code that sets global values
     addValueInjectionLoader({
       newConfig,