Building without `sentry.properties` or env variables

[bertramakers]

We are trying to implement the Sentry SDK in a Next.js project but are running into some problems.
The situation is as follows:

• We have an open-source app in a public repository
• We build our app on GitHub Actions, without environment variables, to then upload some components to Chromatic for visual review
• We build our app once on Jenkins, without environment variables, and then run it on multiple environments (acceptance, testing, production) with different .env files. The fact that we build once and then run the same artifact on multiple environments (with different config) is important to our deployment and testing process.
• To make the points above work, we exclusively use runtime config in our Next app, i.e. publicRuntimeConfig and serverRuntimeConfig which get filled with values from env variables coming from an .env file that gets set only on the actual servers that run the code.

Since we added the @sentry/nextjs package to our app, this approach is broken because apparently the sentry.properties file (which contains a secret and thus cannot be committed in our git repo) or the alternative env variables are required at build time. If I understand correctly this is required at build time because that's the moment that sentry-cli uploads source maps to Sentry.

We could add the required env variables as secrets to our GitHub repository and to Jenkins, but ideally we would just want to disable the sentry-cli step and source map uploads, and work with public source maps instead.

The only part of the Nextjs SDK that we want to use is the webpack plugin that loads the file with the Sentry.init() as soon as possible. (Or a suitable alternative to that)

What would be the best/easiest way to achieve this? I don't see an option to disable sentry-cli and source maps in https://github.com/getsentry/sentry-webpack-plugin#options

Is there another way to have Next call the Sentry.init as soon as possible?

[kamilogorek]

Hey @bertramakers we are working on it. In the meantime see workarounds at #3674 which is also a duplicate of this issue, so I'll let myself close this one. Cheers!