fix(nextjs): Prevent sourceMappingURL stripping from truncating minified chunks

[oesnuj]

While deploying our app (Next.js 16.2.10 turbopack build, @sentry/nextjs 10.68.0, deleteSourcemapsAfterUpload: true), we noticed some JS chunks were shipped cut off mid-file and threw SyntaxError: Invalid or unexpected token on every page load. We traced it to the sourceMappingURL stripping step, and this PR addresses it with a small regex change.

The regex in stripSourceMappingURLComments doesn't check that the comment starts at the beginning of a line:

/\n?\/\/[#@] sourceMappingURL=[^\n]+$/

So it also matches comment-shaped text inside a string literal — and since a minified chunk is a single line, everything from the match to EOF gets deleted:

// minified chunk — comment-shaped text inside a string
const a=1;const worker='self.onmessage=()=>{};\n//# sourceMappingURL=worker.js.map\n';use(worker);const b=2;

// after stripping — truncated mid-string, no longer parseable
const a=1;const worker='self.onmessage=()=>{};\n

In our case the text came from rrweb (the recording engine behind Amplitude Session Replay), which inlines its worker code as a string. The regex is unchanged in 10.73.0 and on current develop.

We fixed it by requiring the match to start at a line start — we've been running this in production via pnpm patch, upstreaming it in case it's useful:

/(?:^|\n)\/\/[#@] sourceMappingURL=[^\s'"`]+$/

While digging around we noticed the repo already does this when reading the comment (debug-id-upload.ts uses /^\s*\/\/# sourceMappingURL=(.*)$/m), so this aligns the stripping side with it. Genuine comments sit on their own line and are stripped exactly as before; string-embedded text no longer matches. Excluding whitespace/quotes from the URL matches how browsers read the value (data: URIs still work) and blocks the template-literal variant of the same issue. The CSS regex gets the same line-start condition.

Added 4 tests — two reproduce the truncation and fail on the old regex, two pin existing behavior.

Would love to hear whether this approach makes sense. If you'd prefer a more minimal change, the URL charset restriction can be dropped — the line-start condition alone fixes the truncation.