Sentry doesn't have access to source maps in production

[Vadorequest]

Status

Community is free to contribute, we won't likely have the time to add this feature

Issue

Sentry doesn't have access to source maps, which makes debug harder.

I do not know how to fix that, I believe it had worked at some point in the past, but may have broken due to some dependency update.

Current configuration

https://www.npmjs.com/package/@zeit/next-source-maps is used to generate source maps

It's configured in next.config.js, see https://github.com/UnlyEd/next-right-now/blob/master/next.config.js#L1-L8

There seems to be additional steps to send the files to Sentry, and they're complicated and require some kind of authentication to upload files to their servers. See https://docs.sentry.io/platforms/javascript/sourcemaps/

Also, it should be enabled for NODE_ENV=production only, not during development (to avoid latency due to source files upload, which would completely break DX)

Sentry logs in development (browser)

https://youtu.be/fr3LX5aGiDI

Sentry logs in development (server)

https://youtu.be/tSqi4A1yslI

Sentry logs in production (server)

https://youtu.be/S2o6YibLnvA

Sentry logs in production (browser)

https://youtu.be/kUUO-1Gyujc

Resources:

• See with-sentry-simple example doesn't work in server although it says it does. vercel/next.js#8106 (comment) for initial discussion
• Source maps info don't show in with-sentry example vercel/next.js#8873
• https://docs.sentry.io/platforms/javascript/sourcemaps/
• https://docs.sentry.io/cli/configuration/
• https://forum.sentry.io/t/sentry-webpack-plugin-and-next-js-sourcemaps/4153/4 experiments (fedback)
• https://docs.sentry.io/error-reporting/configuration/?platform=javascript we may need to define SENTRY_RELEASE and SENTRY_ENVIRONMENT variables, but I believe we do it already at

  next-right-now/src/utils/sentry.ts

  Lines 12 to 17 in 6afd12d

  	Sentry.init({
  	dsn: process.env.SENTRY_DSN,
  	enabled: process.env.NODE_ENV !== 'test',
  	environment: process.env.APP_STAGE,
  	release: process.env.APP_VERSION_RELEASE,
  	});

• https://stackoverflow.com/questions/61011281/next-js-source-maps-with-typescript-on-sentry SO question about how to avoid "leaving the source map publicly available on the server"

[a14m]

I noticed that the error report for sentry is working fine (in the screenshot) but it's from the server... I was wondering if at any point in time the same functionality (showing the error stack from tsx files) had worked from the browser?

[Vadorequest]

Is it working fine? It's not really the source code, it's not minified but it's not the source file either, kind of in-between.

I'll try to throw an error on the browser an update it

[a14m]

Yeah I noticed it's not the source code... your description is actually fine (sorry my bad)

[Vadorequest]

@a14m I've updated and added development sentry logs browser/server and indeed, server is much easier to understand.

[Vadorequest]

@a14m I created a PR to showcase both behaviours in a production environment:
#29

I updated description and added production videos for browser/server sentry logs. It's not that bad IMHO, in development the browser logs are undecipherable but in production it's rather straightforward.

One fun thing is how the app behaves when there is a browser error (https://nrn-v1-ssr-mst-aptd-gcms-lcz-sty-c1-2fr19onwp.now.sh/) when you scroll down it creates 2 apps 😂

[a14m]

Interesting, I don’t have any of those problems... the debug in development works fine (when I have source maps enabled, it’s a bit cryptic unless I’m running next dev but source maps works fine when I serve the generated site locally) but I still haven’t tested it with SSR (or serving from heroku app yet)

[Vadorequest]

From what I could read at vercel/next.js#8873 (comment), it does seem SSR has some role to play, so that could be related. Not sure how.

But anyway, bad source maps in development is not a real issue, what truly matters is production, because that's where we really need them to understand what's going on, and that's my real focus.

The way it currently works feels "good enough" to me.

• The browser displays the real source code, so it's really great.
• The server displays some kind of bundled source code, but it's still readable and still allows to understand from which file the error comes from, and allows to find the line with a bit of digging. Not perfect but good enough.
• Why the app gets visually duplicated stays a mystery to me, probably due to how the error is handled.

[Vadorequest]

Closing this, TL;DR: It works fine in production mode.

[Vadorequest]

Sentry has released @sentry/nextjs which brings built-in source maps. It works for staging/production, not in dev.

See #305