fix(nextjs): Stop SentryWebpackPlugin from uploading unnecessary files

[lobsterkatie]

Though sourcemap uploading using SentryWebpackPlugin is generally quite fast, even when there are a lot of files, there are situations in which it can slow things down a lot.

There are a number of reasons for that, but one of them is that, in the current state, @sentry/nextjs's use of the plugin is pretty indiscriminate - it just uploads anything and everything in the .next folder (which is where nextjs puts all of its built files), during both client and server builds. The lack of specificity leads us to upload files we don't need, and the fact that we don't distinguish between client and server builds means that whichever one happens second not only uploads its own unnecessary files, it also uploads all of the files from the other build (which have already been uploaded), both necessary and unnecessary. More details here.

This PR makes it so that we're much more specific in terms of what we upload, in order to fix both the specificity and the duplication problems.

Notes:

• There's discussion in the linked issue about which non-user sources/maps to upload (things like code from webpack, nextjs itself, etc). In the end, I chose to restrict it to user code (almost - see below), for two reasons. First, non-user code is unlikely to change much (or often) between releases, so if third-party code were included, we'd be uploading lots and lots of copies of the same files. Second, though it's occasionally helpful to be able to see such code in the stacktrace, the vast majority of the time the problem lies in user code. For both reasons, then, including third-party files didn't feel worth it , either in terms of time spent uploading them or space spent storing them.

  (I say it's "almost" restricted to user code because, among other files, the server build generates bundles which are labeled only by numbers (1226.js and such), some of which are user code and some of which are third-party code, and - in this PR at least - I didn't include a way to filter out the latter while making sure to still include the former. This is potentially still a worthwhile thing to do, but the fact that it would mean actually examining the contents of files (rather than just their paths) makes it a more complicated change, which will have to wait for a future PR.)

• In that issue, the topic of HMR (hot module reloading) files also came up. For the moment I also chose to skip those (even though they contain user code), as a) the plugin isn't meant for use in a dev environment, where every change triggers a new build, potentially leading to hundreds of sets of release files being uploaded, and b) we'd face a similar issue of needing to examine more than just the path in order to know what to upload (to avoid uploading all previous iterations of the code at each rebuild).

• Another small issue I fixed, while I was in the relevant code, was to prevent the webpack plugin from injecting the release into bundles which don't need it (like third-party code, or any bundle with no Sentry.init() call). Since this lines up exactly with the files into which we need to inject sentry.server.config.js or sentry.client.config.js, I pulled it out into a function, shouldAddSentryToEntryPoint().

Fixes #3769
Fixes vercel/next.js#26588

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	21.56 KB (0%)
@sentry/browser - Webpack	22.56 KB (0%)
@sentry/react - Webpack	22.59 KB (0%)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	28.99 KB (+0.01% 🔺)