NextJS 13 new app/ folder and Sentry environment variables configuration.

[Marcosld]

Hello, we have a webpage that runs over NextJS and we are looking forward to migrate it to the new app/ folder to be able to use RSC. The main problem we are facing is configuring Sentry properly.

We build our code a single time, and then deploy it over different environments. We used to pass environment config to sentry through https://nextjs.org/docs/app/api-reference/next-config-js/runtime-configuration, as all our pages use SSR. It seems like with app/ folder in NextJS 13 this is no longer possible and environment variables must be read directly from process.env.

As stated here https://nextjs.org/docs/app/building-your-application/configuring/environment-variables, environment variables prefixed with NEXT_PUBLIC (that are bundled automatically into the browser code) will be bundled in build time, so that's not an option for us.

Is it possible to read the environment variables on the server and then call Sentry.init manually on the client code instead of using sentry.client.config.ts file? Have you thought about supporting this some way on the future?

Workarounds I've explored were:

• Replacing through the bundled code on server startup
• Sending an script (with defer option) with the required environment variables to the client that populates window object and then reading it in the sentry.client.config.ts file.

But none seems too convincing to me.

[AbhiPrasad]

Hey @Marcosld - so is the primary issue here that you want each environment to have their own DSN?

One slight hack you can do here is insert the DSN via metadata - and then read the meta tag off the HTML to find the correct DSN. Would that work for you?

[lforst]

You should have access to process.env inside your sentry.server.config.ts file.

[Marcosld]

Yes but we want it in the sentry.client.config.ts file, otherwise we have to rely on these "hacks" to have different DSNs on a multi tenant app for the client

[lforst]

Hm, this is just a limitation in general I believe. sentry.client.config.ts runs as soon as the browser code loads. Inside that file you can do whatever you want to do. I have a hard time imagining how we could have "support" for the use-case you're describing. How would you want this to work?

[Marcosld]

I don't know, I see this is a tricky issue. Perhaps being able to init Sentry SDKs from sentry.client.config.ts file (regarding error / spans capturing) but putting them "on hold" regarding sending traces to the server. Later on, from any code that gets executed client side but has the server side environment variables injected as props, one could set the correct Sentry DSN and transactions and errors would start being sent (?)

[lforst]

Yeah I see what you're going for now. This is already possible but a bit involved and can also be a bit scary. Right now we're not looking to implement such functionality but you might be able to implement it yourself using a custom transport:

Sentry.init({
  transport: (transportOptions) => {
    const xhrTransportPromise = fetch("/fetch/some/config").then((config) =>
      makeXHRTransport({ ...transportOptions, ...config })
    );

    return {
      flush: (timeout) => (await xhrTransportPromise).flush(timeout),
      send: async (request) => (await xhrTransportPromise).send(request),
    };
  },
});