[@sentry/nextjs] @sentry/cli always bundled in production

[belgattitude]

• 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/nextjs - v 6.10.0
• @sentry/webpack-plugin - v 1.16.0

Version:

6.10.0

Description

Right now the @sentry/webpack-plugin (/ @sentry/cli) is required as regular dep, meaning we can't get rid off it in production.

This makes prod bundle much bigger and lead to

• Exceeding lambdas limit of 50Mb (in this case the lambda deployment would fail)
• Lower performance and slow cold start for lambdas (and maybe some 504...)
• Longer and (non-cacheable) installs (needs to download binary at build)

As an example, see a vercel debug based on an example repo https://github.com/belgattitude/nextjs-monorepo-example

Edit: Try a deploy on vercel and check the log with NEXT_DEBUG_FUNCTION_SIZE=1

00:42:46.970 | Serverless Function's pages: api/graphql-sdl.js, api/hello.js, api/rest/poem.js, api/rest/post.js, api/rest/post/[id].js
-- | --
00:42:46.980 | Large Dependencies                    Uncompressed size  Compressed size
00:42:46.980 | node_modules/.prisma/client                     43.4 MB          15.2 MB
00:42:46.980 | node_modules/sharp/vendor                       18.4 MB          7.66 MB
00:42:46.980 | node_modules/@sentry/cli                        17.9 MB          6.78 MB
00:42:46.980 | node_modules/next/dist                          31.9 MB          6.33 MB
00:42:46.980 | node_modules/sass/sass.dart.js                  4.09 MB           610 kB
00:42:46.980 | node_modules/@mui/material                      1.84 MB           567 kB
00:42:46.981 | node_modules/@prisma/client                     1.66 MB           336 kB
00:42:46.981 | node_modules/react-dom/cjs                      1.18 MB           289 kB
00:42:46.981 | node_modules/caniuse-lite/data                   719 kB           278 kB
00:42:46.981 | node_modules/next/node_modules                   740 kB           194 kB
00:42:46.981 | node_modules/micro/node_modules                  360 kB           190 kB
00:42:46.981 | node_modules/encoding/node_modules               329 kB           179 kB
00:42:46.981 | node_modules/iconv-lite/encodings                303 kB           172 kB
00:42:46.981 | node_modules/@next/react-dev-overlay             450 kB           131 kB
00:42:46.981 | node_modules/styled-jsx/node_modules             570 kB           110 kB
00:42:46.981 | All dependencies                                 133 MB          41.4 MB

Fixing

It's not totally clear to me what would be the best to do.

Option 1:

@sentry/nextjs could move @sentry/html-plugin to devDependencies (or peerDeps/optional), but I'm not sure as it's included in nextjs.config.js so maybe need some more work to be sure the plugin is not required for production builds. A proposal here: #3866

Option 2:

@sentry/html-webpack plugin, move @sentry/cli to devDependencie (or peerDeps/optional)... That would be sufficient as the it's actually the one that increase size significantly (17Mb).

Edit

Option 3:

Ditch @sentry/cli in favour of a custom lightweight sourcemap uploader (That would be the more universal solution)

Option 4:

Possible too, add an option to vercel/nft / nextjs to ignore sentry binary... Would solve vercel problem, but then quid of serverless, netlify...

I could provide some P/R's but let me know what would the recommended approach...

[kamilogorek]

webpack plugin has been moved to dev deps. Let me know if this issue will still persist after next release.

[lobsterkatie]

webpack plugin has been moved to dev deps. Let me know if this issue will still persist after next release.

Hmmm. Not having seen this, I moved it back, because SDK users need it as part of building their app, and if it's in our dev dependencies, it'll only install for us, not for folks who yarn install our SDK. That said, @belgattitude, can you help me understand how you're ending up with it in your bundle? It's only used as part of the build process, so there's no reason that I can think of why webpack would be including it in your built app.

How are you getting the logs you included in the PR description?

UPDATE: Stumbled across an undocumented NEXT_DEBUG_FUNCTION_SIZE env var which outputs the size breakdown you posted, and I now realize that a) you were talking about your serverless lambdas, not your browser bundle, and b) I'm also ending up with @sentry/cli included (which makes it clear that on this score, the bundle analyzer is only really helpful for the front end). Boo.

I notice that we're also both ending up with caniuse data, which I'd assume similarly has no reason to be there. I tried this trick, but it didn't seem to make a difference. Am I missing something, though? Why aren't these things getting treeshaken out? It does seem like the lambda-creation process is separate from the server bundle creation process, but still...

In any case, as it happens, I'm actually trying to get more insight into how the lamdas are created for other reasons (was working on it just today, in fact), so perhaps getting a handle on that will shed some light here as well.

[lobsterkatie]

Reopening this because it isn't solved now that I undid the change.

[belgattitude]

@lobsterkatie sorry for long delays,

I haven't looked thoroughly, but yes moving to devDeps is quite a strong statement somehow :)

Something that might help you:

Working with NEXT_DEBUG_FUNCTION_SIZE is not very easy when going testing. Personally I created a little wrapper over https://github.com/vercel/nft to trace what is included in the server build. Very convenient.

I haven't had the time to look into the code, but I'll try next week.

[stnwk]

Spend the past couple days to debug this exact issue :/

I'm working on a NextJS app, deployed on Vercel. We're using the @sentry/nextjs integration and have one serverless api function that makes screenshots using puppeteer-core and chrome-aws-lambda. Both of those packages together are barely under 50MB so that you can use it in a serverless function. So far, so good.

But because of this issue sentry is adding a couple megabytes to the compressed lambda function, which brings it over the max limit of 50MB and therefore fails the build. Even worse, the sentry plugin seems to include a lot more unrelated dependencies in the lambda function.

This issue a is total roadblock for us: Is there any workaround or do I need to stop using sentry?

[belgattitude]

@stnwk @lobsterkatie

Is there any workaround or do I need to stop using sentry?

If you're hitting serverless limits the @sentry/nextjs is not the way to go IMHO. (I would add if you're going close to 40Mb, lambdas would already start giving 504 from time to time, cold starts are too long depending where you host them).

As workaround it's possible to use sentry for the browser part only, you'll have to go back in time in the examples, ie https://github.com/vercel/next.js/tree/6aef4b8445472c53c4a4c39005319c2fc73e44de/examples/with-sentry. that's more or less the direction I took for sandboxes (prod is on docker/k8s so it's less a problem). For monitoring api routes we actually send to datadog.

But I feel there must be some more thinking related to @sentry/nextjs.

Personally and if it's only used to upload sourcemaps I would ditch @sentry/cli totally in favour of lightweigtht js code (or even wasm). I fear that It would be almost impossible to shrink the size of the binaries in the current state (not even talking that on alpine the wrong binary is picked when installing and the fact that sentry.properties looks weird for js devs, etc).

Nextjs, lambdas, serverless... paradigms requires deps to be light as possible. @sentry/nextjs should consider this as a requirement to ease adoption.

Cause both sentry and nextjs are wonderful products 😄

PS: @stnwk your use case with pupeeter might look very specific... But actually in many setup we'll add sharp, prisma, graphql and why not redis ?.. add @sentry/nextjs and the limit is easily reached.