Repository navigation
[Nuxt] Look for SDK init files in Nuxt layers #14345
Description
Problem Statement
We use Nuxt layers to have a common base for multiple projects. After adding the @sentry/nuxt module and the client/server configuration files (sentry.*.config.ts) to the base layer I had a hard time figuring out why sourcemaps weren't uploaded and Sentry wasn't initialised in the applications based on this layer.
Only after diving into
and I figured out that I had to put these files into the apps, as they wouldn't be found in the base layer.After I did that things started working as expected (I also moved/duplicated the sentry config key from the base layer to the apps nuxt.config file, not sure if that was necessary).
Solution Brainstorm
Either somehow involve layers into the resolution of these init files, or cleary document that layer based configuration is not supported.
Reacted by Muhammad Mahmoud, Jaap Roes, francoisauclair911, Jonas Thelemann, Simon Maass, Maksymilian Tomczyk, Florent Catiau-Tristant, Kaito Queiroz, Maxime Pauvert and Andreas Sonnleitner
Metadata
Metadata
Assignees
Projects
- Status
Activity
andreiborza commentedon Nov 18, 2024
Hey @jaap3, thanks for digging around and filing this. Layers have not yet been our priority, but we'll look into that.
cc @s1gr1d.
s1gr1d commentedon Nov 18, 2024
Hy, thanks for writing in. Supporting layers is still on the roadmap.
Right now, you have to set up Sentry for every layer.
What would be the ideal setup for you as a person using layers?
I was thinking about letting developers set up Sentry in the base/default layer and this configuration is used for all other layers. The other layers are able to overwrite the Sentry config. Would that make sense?
jaap3 commentedon Nov 19, 2024
@s1gr1d yes, setting up Sentry in the base layer was the approach I was going for. I can also imagine having some specific Sentry layer if a more granular layers approach is preferred, but I personally don't have a need for that.
Since all applications use their own DSN some mechanism of overriding that is required. In addition we have a distinct version for each application, so we set that as well. We picked the
appConfigfile to do so.One snag that I ran into was that in our monorepo multiple applications can be built from the same commit. Since I believe a release in Sentry needs to be unique I had to figure out a way to manually set a version in the build/sourcemap configuration (see also #14337) (I wasn't able to use the
appConfigin the Nuxt config file, so there is some duplication there). I believe this version can trickle down to the Sentry client initialisation, but I currently still explicitly set the version in theSentry.initcall.13 remaining items
Xenossolitarius commentedon May 22, 2025
Yea although it's not really a problem to copy paste this stuff around it would be greatly appreciated if the "latest" layer to the entry was the source of the build configuration. I may even indeed open up a PR for this if you want. It's really not so hard to implement. 30+ lines. at the start of the module :)
s1gr1d commentedon May 22, 2025
Yeah, just adding support for the latest layer would actually be a good idea! If you want to contribute this, you can tag me as a reviewer.
feat(nuxt): Added support for nuxt layers (getsentry#14345)
feat(nuxt): Added support for nuxt layers (#16372)
github-actions commentedon May 28, 2025
A PR closing this issue has just been released 🚀
This issue was referenced by PR #16372, which was included in the 9.23.0 release.