Is it possible to move `sentry.client.config.js`, `sentry.server.config.js` to a custom folder?

[thiagobraga]

Hi friends.

The title says it all. Is it possible to move the above files to a config folder for example?

• sentry.client.config.js
• sentry.server.config.js
• sentry.properties
• .sentryclirc

Our project is new, hasn't been released yet, and we already have several files in the root.

Just FYI, we're using:

"@sentry/nextjs": "^6.15.0",
"next": "10.1.3",
"webpack": "5.36.0"

Thanks anyway. :)

[AbhiPrasad]

Hey thanks for writing in.

There isn’t a first class option to do this at the moment, but there is a PR open to add this that we are evaluating: #4187

[lobsterkatie]

Hi, @thiagobraga.

We discussed it as a team and have decided not to incorporate the PR Abhi linked, but that doesn't mean you can't get things a little more streamlined. Looking at the four files you've named:

• sentry.server.config.js and sentry.client.config.js need to remain at the root level of your project.
• sentry.properties and .sentryclirc, on the other hand, can be eliminated entirely. As the name of the latter implies, these aren't actually SDK config files at all, but rather config files for sentry-cli (which our webpack plugin uses under the hood to upload sourcemaps to Sentry), and everything in them can be set in other ways.

  • sentryclirc: This holds your auth token, and is a separate file from sentry.properties simply so that it can be kept out of git while still allowing you to commit the rest of your sentry-cli config. In other words, it only exists locally. If you'd rather use a different way to set that token on your machine, there are a number of other options for doing so in our sentry-cli docs.

    (In prod, the token needs to be set as an environment secret, SENTRY_AUTH_TOKEN.)

  • sentry.properties: The default URL is only relevant if you're hosting sentry yourself; if you're a SAAS customer, it doesn't need to be set at all. The path to the sentry-cli executable can similarly be eliminated unless you've purposefully moved said executable out of node_modules for some reason.

    All that remains at that point is setting your org and project name. You can use the environment variables SENTRY_ORG and SENTRY_PROJECT, or you can set the org and project keys in your SentryWebpackPluginOptions in next.config.js.

I've put a ticket into our backlog to think about incorporating some of this streamlining into our default setup, also.

[UPDATE: I realized that PR had a slightly different motivation than the question addressed here (shared config rather than grouping of config files), though it would have addressed both their issue and yours. I've added a suggestion for their situation to my response there.]

[geoshak]

We just implemented sentry on our first NextJS web-app and would really like to have this possibility.
Our code organization is very minimalist, and we try to keep files/folders real tidy and clean.

Adding sentry almost doubled the files on the root folder.
We'll have several more web-apps/server code where we could use sentry, and this would be a drawback against other libs with cleaner setup.

Couldn't we at least consolidate config in one (01) file?

[jamesrweb]

I agree with @geoshak, it is quite annoying to be forced to have the files in the root when pretty much everything else supports a --config option or some form of custom configuration file to unify settings. It is just a lot of noise for what should, in my opinion, be a single file all-in-one config if it MUST be in the root.

[AbhiPrasad]

We did have a PR for this that we decided to move away from #6957

I think we're always a little hesitant expanding API surface area because of the possibility of introducing bugs - especially since nextjs themselves are pretty liberal between what they change between minors under the hood (the config files are bundled via a webpack plugin we inject, so the logic managing it can be a little delicate).

For now we're not going to re-evaluate this decision, though thank you for the feedback @jamesrweb.

Couldn't we at least consolidate config in one (01) file?

We can't do this because we don't want to run server/client/edge code on the wrong runtimes - we need to make sure that everything is tree-shaken and isolated properly, and separate config files are the best way to accomplish this while minimizing magic.

[jamesrweb]

I don't want magic either but nextjs does allow you to hook into the Webpack builder itself via the config and the runtime is also passed in there to my understanding. Perhaps exporting a config to use there from the library would be a better option to avoid the file system altogether. Then users could just use the defaults or override as desired in the next config build step. Did you consider that option yet?

[jamesrweb]

Main point is that the current implementation is yes, stable but also, clutters the root unnecessarily (imo).

[lforst]

nextjs does allow you to hook into the Webpack builder itself via the config and the runtime is also passed in there to my understanding

Yes, we're already using this.

Perhaps exporting a config to use there from the library would be a better option to avoid the file system altogether.

How would this look like? You generally don't want application code (which sentry.(client|server|edge).config.js are) inside your webpack config.

Main point is that the current implementation is yes, stable but also, clutters the root unnecessarily (imo).

I can see that. This is simply not a priority for us right now.

[ozyman42]

Typically you'd use environment variables to get custom configuration at runtime, rather than these highly unusual config files. There should be an option to read from specific environment variables whenever these files are missing.

For any customization which isn't a static value (such as integrations or transports), why couldn't someone just call Sentry.init in their own module? Perhaps the implementation for some /health API imports some custom sentry initialization module I create in the src folder of my next app to ensure it's initialized on startup.

In summary the requirement of sentry.*.config.js files in the root of a project is unnecessary given the industry standard alternatives.