@sentry/nextjs Webpack 5 code duplication bug

[pgrippi]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other: @sentry/nextjs

Version:

6.4.1

Description

During the process of upgrading one of our next.js applications from webpack 4 to webpack 5 I stumbled upon a bug where using withSentryConfig causes webpack 5 to duplicate dependencies in the final output. Using the webpack bundle analyzer I can see that packages normally bundled in _app also get their own shared bundle

Without withSentryConfig:

Using withSentryConfig: (Notice that @apollo/client is now included in both _app and the 675- bundle)

I've created a simple app using the with-apollo template that reproduces the issue: https://github.com/pgrippi/sentry-nextjs-code-duplication-bug.

You can modify next.config.js, swapping the module.exports statements and running yarn build to see the bundle output difference

To clarify the issue not limited to @apollo/client, it looks like most modules imported from npm that appear in both _app and other pages get duplicated, the apollo client is just very noticeable given its large footprint

[travisbloom]

Can confirm I'm seeing similar duplication issues, including duplicate copies of next, apollo, and sentry

[adrienrn]

Hi,

I can confirm the issue as well

Package + Version

[ ] @sentry/browser
[ ] @sentry/node
[ ] raven-js
[ ] raven-node (raven for node)
[x] other: @sentry/nextjs

Version:

6.4.0

Other

"next": "^10.2.2",

next.config.js

require('dotenv').config();

const { withSentryConfig } = require('@sentry/nextjs');
const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.BUNDLE_ANALYZE === 'true',
});
const MomentLocaleRemovalPlugin = require('moment-locales-webpack-plugin');
const { nextI18NextRewrites } = require('next-i18next/rewrites');
const withTranspile = require('next-transpile-modules')([/* ... */]);

const SentryWebpackPluginOptions = {
  // Additional config options for the Sentry Webpack plugin. Keep in mind that
  // the following options are set automatically, and overriding them is not
  // recommended:
  //   release, url, org, project, authToken, configFile, stripPrefix,
  //   urlPrefix, include, ignore
  // For all available options, see:
  // https://github.com/getsentry/sentry-webpack-plugin#options.
};

const moduleExports = withBundleAnalyzer(
  withTranspile({
    bundleAnalyzerConfig: {
      server: {
        analyzerMode: 'static',
        reportFilename: '../.next/server.html',
      },
      browser: {
        analyzerMode: 'static',
        reportFilename: '../.next/client.html',
      },
    },
    future: {
      webpack5: true,
    },
    webpack: (config, { buildId, webpack }) => {
      config.plugins = config.plugins || [];
      config.plugins.push(new MomentLocaleRemovalPlugin());
      config.plugins.push(
        new webpack.DefinePlugin({ 'process.env.NEXT_BUILD_ID': JSON.stringify(buildId) })
      );

      return config;
    },
  })
);

module.exports = withSentryConfig(moduleExports, SentryWebpackPluginOptions);

Using @sentry/nextjs

info  - Collecting page data  
info  - Finalizing page optimization  

Page                                                                  Size     First Load JS
┌ λ /                                                                 5.14 kB         847 kB
├   /_app                                                             0 B             456 kB

Without:

Making a tiny change in the next.config.js, keeping the rest as is:

// module.exports = withSentryConfig(moduleExports, SentryWebpackPluginOptions);
module.exports = moduleExports;

info  - Collecting page data  
info  - Finalizing page optimization  

Page                                                                  Size     First Load JS
┌ λ /                                                                 2.79 kB         493 kB
├   /_app                                                             0 B             406 kB

[steida]

I have the same issue with @sentry/nextjs. It started happening with Next.js 10.2.1 where Sokra added some Webpack optimizations.

[lobsterkatie]

I think this may be responsible for a blocker I'm currently experiencing, deploying my test app to vercel. Will investigate today and let you all know what I find out.

[adrienrn]

I've been reading through this: vercel/next.js@v10.2.0...v10.2.1
Try to see if I could notice anything that looks related or suspicious.

Out of the many changes, this commit may be interesting, and especially changes made to chunks:
vercel/next.js@1d643eb#diff-35e60cb9cfc6f14c2998799e7e5a28e5adfd6ededc273851531da3a1e506b0d4R472-R478

This commit appears to be touching to the main entry when webpack5 is enabled

Now, withSentryConfig seems to do 2 things:

• Register @sentry/webpack-plugin
• Inject sentry.client.confg.js and sentry.server.config.js in the main entry

Here's where I am right now:

Page                                                                  Size     First Load JS
┌ λ /                                                                 5.17 kB         915 kB
├   /_app                                                             0 B             500 kB
...
├ λ /team                                                             2.57 kB         862 kB
└ λ /terms-of-service                                                 22.4 kB         773 kB

+ First Load JS shared by all                                         500 kB
  ├ chunks/framework.40b4e2.js                                        45.6 kB
  ├ chunks/main.c17031.js                                             75.4 kB
  ├ chunks/pages/_app.a84967.js                                       376 kB
  └ chunks/webpack.d67f8d.js                                          3 kB

When registering/not-registering the webpack plugin, it has no influence to the build size (not surprising).

Commenting the following line: https://github.com/getsentry/sentry-javascript/blob/master/packages/nextjs/src/utils/config.ts#L156, gives me a normal build report:

Page                                                                  Size     First Load JS
┌ λ /                                                                 2.87 kB         516 kB
├   /_app                                                             0 B             429 kB
...
├ λ /team                                                             658 B           514 kB
└ λ /terms-of-service                                                 22.4 kB         520 kB
+ First Load JS shared by all                                         429 kB
  ├ chunks/framework.40b4e2.js                                        45.6 kB
  ├ chunks/main.dcd489.js                                             18.1 kB
  ├ chunks/pages/_app.d312eb.js                                       362 kB
  └ chunks/webpack.a6bea8.js                                          3 kB

However, when I comment the following line: https://github.com/getsentry/sentry-javascript/blob/master/packages/nextjs/src/utils/config.ts#L95, it does not change the size at all.

So it seems to be less related to the _injectFile logic than to the async-ness and await origEntryProperty(); or delete newEntryProperty['main.js'];. I have limited understanding of the actual issue but I figured this might be helpful to someone who does.

[lobsterkatie]

Thanks for all of that research, @adrienrn! I think you're onto something, though I haven't yet figured out exactly what's going wrong (or therefore how to fix it). I can definitely replicate the problem, though. In my bundle, I end up with two copies of next and three (!) copies of sentry. 😓

The code that you were looking at in our config.ts has changed a bit in the meantime, but one thing I can say, since you mentioned it, is that the hack involving deleting main.js is gone, which means next can again handle that for itself.

It's a holiday starting tomorrow (for the US contingent of the team, at least, which includes me) but if it isn't solved before then, I can keep digging next week.

[adrienrn]

As a workaround, I removed withSentryConfig, registered the webpack plugin myself and called init in the pages/_app.js. I wanted to keep @sentry/nextjs still, hence the hybrid solution between with and without based off of a previous commit of the with-sentry next example. It's truly a temporary workaround.

1. Defined a global in next.config.js:

      config.plugins.push(
        new webpack.DefinePlugin({
          'process.env.NEXT_IS_SERVER': JSON.stringify(isServer.toString()),
        })
      );

2. Slightly modified ./sentry.client.config.js and ./sentry.server.config.js to export their code as a function:

// This file configures the initialization of Sentry on the browser.
// The config you add here will be used whenever a page is visited.
// https://docs.sentry.io/platforms/javascript/guides/nextjs/
import { CaptureConsole as CaptureConsoleIntegration } from '@sentry/integrations';
import { init as initSentry } from '@sentry/nextjs';
import { Integrations as TracingIntegrations } from '@sentry/tracing';

const SENTRY_DSN = process.env.SENTRY_DSN || process.env.NEXT_PUBLIC_SENTRY_DSN;

function init() {
  initSentry({
    dsn: SENTRY_DSN,
    // ...rest of my options
  });
}

export default init;

3. Then, created a ./sentry.bridge.config.js looking like that:

import initSentryClient from './sentry.client.config.js';
import initSentryServer from './sentry.server.config.js';

const init = process.env.NEXT_IS_SERVER === 'true' ? initSentryServer : initSentryClient;

export default init;

4. Finally, in pages/_app.js, I'm importing init from my bridge file as follows:

import initSentry from '../sentry.bridge.config';

initSentry();

class MyApp extends App {
// ...

---

For context, we updated Sentry while setting up the performance tracing (which looks awesome so far btw!), and Next.js ^10.1 for the webpack 5 niceties. This is all part of a performance initiative, slowly grinding kb from our bundle - among many other things. All this to say that while bugs happen and all this, I couldn't afford an additional 400kb 🎃 given the context and why I set out to find a workaround.

[lobsterkatie]

@pgrippi @travisbloom @adrienrn @steida Can you all please try upgrading to @sentry/nextjs 6.5.0 or greater? I believe I understand the cause of this bug, and if I do, then it's fixed in that version.

More specifically, #3625 (which is included in #3580) fixed a bug where the webpack entry property was incorrectly converted to a promise, rather than a function which returns a promise. As a result, this code was broken - originalEntry wasn't a function, so it wasn't awaited, and therefore never turned into a real value; the promise that it remained didn't have the keys necessary for the final for-loop; and therefore none of the dependsOn code (which would have factored the duplication out) could run.

Can y'all please let me know if upgrading works for you?

[pgrippi]

@lobsterkatie I upgraded our production app and can confirm that 6.5.1 has fixed the issue!

Thanks for looking into this! 😁

[steida]

@lobsterkatie Yep, it works, thank you. Btw, can you somehow reduce Sentry for Next.js itself? I don't know what all it does, but it's huge for plain error reporting I suppose. Which feature(s) needs so much code? Thank you.