feat(nuxt): Setup source maps with vite config #13018
Conversation
| export default defineNuxtConfig({ | ||
| modules: ['@sentry/nuxt/module'], | ||
| sentry: { | ||
| debug: true, |
There was a problem hiding this comment.
hmm, no strong feelings, but it feels a bit confusing that this only turns on debug mode for the vite plugin, right? It seems easy to think that this also enables debug mode for sentry itself 🤔 would it make sense to name this in a different, more specific way, e.g. viteDebug or debugVitePlugin, something along these lines? Not sure how this works in other SDKs though, if we do the same there it's probably fine.
There was a problem hiding this comment.
I would keep a top-level debug option like this. Makes it very easy to ask users to enable debug mode to debug all issues related to build time stuff.
There was a problem hiding this comment.
I was thinking about the same actually before creating this PR. But this debug option is actually quite nice for the build-time debug. The debug flag in init only works during runtime. To make it more explicit, this could be renamed to buildDebug?
There was a problem hiding this comment.
Fwiw (no strong opinions but from having dealt with this before): We have this pattern of multiple debug properties in different files in SvelteKit and Astro and so far people haven't complained about it. If we point out well in the JSDoc what kind of logging this specific option enables, I think going simply with debug is fine.
Especially considering, this flag can be used everywhere within the nuxt module (so not just within the vite plugin I assume) I wouldn't give it a too specific name.
packages/nuxt/src/common/types.ts
Outdated
| * The SDK options are mostly handled inside the `init` function in separate files (see type `SentryNuxtOptions`). | ||
| * Other options, such as the source maps options are added inside the `nuxt.config.ts` to be able to access those options during build time and modify the Vite config. | ||
| */ | ||
| export type SentryNuxtModuleOptions = Pick<Options, 'debug'> & SourceMapsOptions; |
There was a problem hiding this comment.
- Any reason you picked
debugoff the SDK options? I would just add a new debug field and document it separately, because it has nothing to do with the SDK init debug option. - I would phrase the JS doc for this type differently. Imagine you are a user hovering over the type. I would start with something like "Build options used by the Sentry Nuxt SDK. ...". In general I would steer away from describing how things are not and describe what they are.
- I would restructure this type and the
SourceMapsOptionstype so that it is not just an interface with one property.
packages/nuxt/src/vite/sourceMaps.ts
Outdated
| }); | ||
|
|
||
| viteInlineConfig.plugins = viteInlineConfig.plugins || []; | ||
| viteInlineConfig.plugins.push(...sentryPlugins); |
There was a problem hiding this comment.
I think you should be able to do
| viteInlineConfig.plugins.push(...sentryPlugins); | |
| viteInlineConfig.plugins.push(sentryPlugins); |
and I highly recommend because you theoretically can not assume that the vite plugin is an array.
| export default defineNuxtConfig({ | ||
| modules: ['@sentry/nuxt/module'], | ||
| sentry: { | ||
| debug: true, |
There was a problem hiding this comment.
Fwiw (no strong opinions but from having dealt with this before): We have this pattern of multiple debug properties in different files in SvelteKit and Astro and so far people haven't complained about it. If we point out well in the JSDoc what kind of logging this specific option enables, I think going simply with debug is fine.
Especially considering, this flag can be used everywhere within the nuxt module (so not just within the vite plugin I assume) I wouldn't give it a too specific name.
|
|
||
| if ((sourceMapsUploadOptions.enabled ?? true) && viteInlineConfig.mode !== 'development') { | ||
| const sentryPlugins = sentryVitePlugin({ | ||
| org: sourceMapsUploadOptions.org ?? process.env.SENTRY_ORG, |
There was a problem hiding this comment.
l: Do we need to pass in the env variable fallbacks explicitly? the plugin itself should pick them up, right?
| viteInlineConfig.plugins.push(...sentryPlugins); | ||
|
|
||
| viteInlineConfig.build = viteInlineConfig.build || {}; | ||
| viteInlineConfig.build.sourcemap = true; |
There was a problem hiding this comment.
m: If viteInlineConfig.build.sourcemap wasn't true before we set it, I'd recommend to log out a warning that we're changing their build config to enable emitting source maps. It's fine to do that but users are worried that their source maps then get deployed to prod.
I'd recommend we expose the filesToDeleteAfterUpload option from the plugin and hint them in the warning that they should set it if they want to delete source maps afterwards again.
| @@ -108,8 +108,8 @@ export async function makeCustomSentryVitePlugins(options?: CustomSentryVitePlug | |||
|
|
|||
| // Modify the config to generate source maps | |||
| config: config => { | |||
| const sourceMapsPreviouslyEnabled = !config.build?.sourcemap; | |||
| if (debug && sourceMapsPreviouslyEnabled) { | |||
| const sourceMapsPreviouslyNotEnabled = !config.build?.sourcemap; | |||
There was a problem hiding this comment.
lock changes are from this PR: #12920
Closes #13017