[nextjs] Extend default sourcemaps ignore (#18938) to client-side stub chunks that never emit sourcemaps

[sakuga-cmd]

Problem Statement

@sentry/nextjs 10.43.0 with a Next.js 15.5.14 (webpack) App Router project: the client-side source map upload prints dozens of warnings for chunks that by construction never emit sourcemaps:

~/b0f41f6b-e36f-409b-817f-921f7d295a7b-155.js (no sourcemap found, debug id b0f41f6b-...)
  - warning: could not determine a source map reference (Could not auto-detect referenced sourcemap for ~/b0f41f6b-...-155.js)

In our production builds these were ~95 warnings per deploy. We traced every one of them to two categories of client chunks:

1. App Router client stubs — static/chunks/app/**/route-<hash>.js (one per API route / metadata route), loading-<hash>.js, _not-found/page-<hash>.js, and page-<hash>.js stubs of fully server-rendered pages. Each is ~600–980 bytes: the Sentry debug-id snippet plus a single empty webpack module ({84441:()=>{}}). Webpack emits no .map for them.
2. Tiny lazy plugin chunks — numbered chunks of ~600 bytes (in our case Capacitor web plugin stubs like SplashScreenWeb, HapticsWeb registered via registerPlugin(..., { web: () => import(...) })). Also emitted without .map.

PR #18938 (released in 10.37.0, closing #18872) already solved exactly this class of noise for framework internals/manifests, with the rationale “these will never emit sourcemaps and we just waste time processing these files”. The client-side stubs above are the same situation, but they are not covered by the default ignore list.

User-side workaround status: sourcemaps.ignore globs work for the named stubs (**/static/chunks/app/**/route-*.js, loading-*.js, _not-found/** — this removed ~89 of ~95 warnings for us, merging with the defaults as expected). However the numbered lazy chunks cannot be targeted by any stable glob — their names are content-hashed numerics that change between builds, so a handful of warnings per deploy remain unfixable from userland.

Solution Brainstorm

• Extend the default ignore list approach of feat(nextjs): Update default ignore list for sourcemaps #18938 to App Router client stubs (static/chunks/app/**/route-*.js, loading-*.js, _not-found/**), and/or
• More generally: skip the “could not determine a source map reference” warning for chunks for which webpack emitted no sourcemap and that contain no module code beyond the injected debug-id snippet — those can never benefit from an artifact upload anyway.

Environment: @sentry/nextjs 10.43.0, @sentry/webpack-plugin 5.2.0, Next.js 15.5.14 (webpack build, not Turbopack), widenClientFileUpload: true, deployed on Vercel.

[linear-code]

JS-3006

[isaacs]

Thanks for reporting this. You are highlighting a real issue; these warnings are clearly just noise. However, the glob-based approach suggested, adding page-*/loading-*/_not-found to the default set, would have the consequence of potentially ignoring files that contain actual transformed user code, resulting in their sourcemaps not being uploaded, which is a strictly worse failure. This is why the set ignored in #18938 was limited in the way it was, so that it could only affect files that are guaranteed to not be transformed from any user code that would need sourcemaps.

Your second idea, to suppress/downgrade the warning when a debug-id'd artifact has no referenced map, is much safer, and incidentally also fixes the numbered chunks you can't glob. I think this is best solved on the bundler-plugins or CLI level, rather than the nextjs SDK.

In the meantime, the userland sourcemaps.ignore globs remains the recommended workaround for the named stubs, but as you point out, it's not a complete fix, so you still get some noise from the generated hash-named files.

@timfish or @chargome Can you weigh in on this assessment? Specifically, if you think this is a reasonable approach?

More generally: skip the “could not determine a source map reference” warning for chunks for which webpack emitted no sourcemap and that contain no module code beyond the injected debug-id snippet — those can never benefit from an artifact upload anyway.

[timfish]

We've also had this reported for Rolldown:

• False "no sourcemap found" warnings for Rolldown synthetic loader chunks (Vite 8) sentry-javascript-bundler-plugins#898

The warning comes from the Setry CLI. Can we reliably identify these chunks without sourcemaps?