nondeterministic chunk names when using plugin

[khalilsarwari]

Environment

What version are you running?

I believe version 1.20.0 of the plugin, 7.38 of sentry, 13.0.5 of nextjs.

"node_modules/@sentry/webpack-plugin": {
"resolved": "https://registry.npmjs.org/@sentry/webpack-plugin/-/webpack-plugin-1.20.0.tgz",
"@sentry/cli": "^1.74.6",

"@sentry/nextjs": {
"resolved": "https://registry.npmjs.org/@sentry/nextjs/-/nextjs-7.38.0.tgz",
"@sentry/core": "7.38.0",
"@sentry/integrations": "7.38.0",
"@sentry/node": "7.38.0",
"@sentry/react": "7.38.0",
"@sentry/tracing": "7.38.0",
"@sentry/types": "7.38.0",
"@sentry/utils": "7.38.0",
"@sentry/webpack-plugin": "1.20.0",

next version: 13.0.5

Here is an excerpt of my next.config.js (intentionally using as close to empty options as possible to reduce chance of error):

const moduleExports = 
   {
    reactStrictMode: true,
    experimental: {
      appDir: true,
      }
      ...
    sentry: {
    }
 };

const sentryWebpackPluginOptions = {
silent: true
};

module.exports = withSentryConfig(moduleExports, sentryWebpackPluginOptions);

Steps to Reproduce

1. rm -rf .next/ && SENTRY_RELEASE=asdfasf npm run build
2. ls .next/static/chunks/
3. saw that webpack-95ee68f5578f47f6.js changed to webpack-ca75b5dd44d18fda.js if I rerun from step 1.

Expected Result

The name of the chunk should have stayed the same, since none of the configuration or files changed.
If I remove the plugin by changing:

module.exports = withSentryConfig(moduleExports, sentryWebpackPluginOptions)

to

module.exports = moduleExports

the chunk name does indeed stay the same. This issue only happens with the webpack chunk, not with main or app chunks or any of the others.

Actual Result

The name of the webpack chunk changes from run to run; it is fine if it changes when adding/removing the plugin.
Once the plugin is added though, it shouldn't be changing from run to run when there are no other file changes being made.

Any ideas why this is happening? I am not sure what the link is here, but it is messing up production deployments since the webpack chunk file goes by a different name on each production instance (the same app is being npm run build separately on each instance), resulting in 404 errors depending on how the load balancer directs the requests.
(like request to _next/static/chunks/webpack-d95ad6f27677beeb.js -> 404 error)

[khalilsarwari]

After some more digging, it seems it may just be an appDir bug in next (even though in this case the plugin has some effect on the hashes):

vercel/next.js#45659

[rkriauciukas-freesat]

Similar issue here - with Sentry plugin enabled, I cannot find a configuration for splitChunks to ensure my serviceWorker file (explicit chunk in cacheGroups) gets generated with correct Webpack runtime code. Even though explicit serviceWorker.js chunk file gets output, the chunk gets "overlapped" with "commons" chunk and contains then references to "window" object - which is obviously not available in WebWorker context. Disabling the plugin resolves the issue and serviceWorker.js file runs just fine.

Initially I was really baffled and wasted hours trying to understand what is causing the difference between my local PC builds and ones on Jenkins. Apparently on Jenkins we pass in SENTRY_AUTH_TOKEN env variable to activate the Sentry Webpack plugin to upload the sourcemaps.

EDIT: After checking once more the docs, I've found entries prop of the plugin. Set entries: ['app'] so that Sentry version gets injected only into the app chunk - which solved the issue of my serviceWorker.js being injected with bad Webpack runtime code referencing window object.

[leonardofaria]

I build next.js twice in my CI (one with source maps for Sentry and one for production). The artifacts are uploaded however Sentry is unable to find the right source map for the exception, potentially due to the fact that different builds generate different filenames (more here: vercel/next.js#49230)

In the issue above and in my case, framework.js is created with different hashes, making impossible to Sentry to un-minify the files

[lforst]

@leonardofaria Yes, however, this is a limitation of Next.js. The recommended way to upload sourcemaps for Next.js to Sentry is to use the Next.js SDK and upload sourcemaps whenever you do a production build (not 2 build runs). This is very likely not gonna change.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[Allan-Nava]

Any news?

[lforst]

@Allan-Nava No currently not. You would see it in this issue.