Split out from #86 / PR #198 review.
Problem
src/instrumentation-client.ts tags browser-side Sentry events with:
environment: process.env.NEXT_PUBLIC_VERCEL_ENV || process.env.NODE_ENV
Unlike VERCEL_ENV, Vercel does not populate NEXT_PUBLIC_VERCEL_ENV automatically — it has to be set explicitly in project settings. Nothing in the repo asserts that it is.
If it is missing, the expression falls through to NODE_ENV, which is production in any deployed build. Every client-side error from a preview deployment is then reported to Sentry tagged production.
That is a silent failure with real cost: it pollutes production error rates with preview noise, and makes preview-only regressions invisible when filtering by environment. The server-side configs are unaffected — sentry.server.config.ts and sentry.edge.config.ts use VERCEL_ENV, which Vercel does set.
Verify first
Check whether NEXT_PUBLIC_VERCEL_ENV is actually set in the Vercel project across all three environments. It may already be configured, in which case this is only about preventing regression.
Options
- Assert it.
.env.schema already declares it @optional @public @type=enum(development, preview, production). Tightening to required in preview/production (@required=not(forEnv(development))) would fail the build when it is missing, instead of silently mislabelling. This is the fix the varlock adoption makes cheap.
- Derive it. Set it from
VERCEL_ENV in the schema (NEXT_PUBLIC_VERCEL_ENV=$VERCEL_ENV) so it cannot drift from the server-side value. Removes the manual project-settings step entirely.
- Document only. Note the requirement and rely on project settings.
Option 2 is probably right — it eliminates the class of error rather than detecting it, and the two values should never legitimately disagree.
References
src/instrumentation-client.ts — the fallback expression
src/sentry.server.config.ts, src/sentry.edge.config.ts — server-side equivalents using VERCEL_ENV
.env.schema — both vars declared
Split out from #86 / PR #198 review.
Problem
src/instrumentation-client.tstags browser-side Sentry events with:Unlike
VERCEL_ENV, Vercel does not populateNEXT_PUBLIC_VERCEL_ENVautomatically — it has to be set explicitly in project settings. Nothing in the repo asserts that it is.If it is missing, the expression falls through to
NODE_ENV, which isproductionin any deployed build. Every client-side error from a preview deployment is then reported to Sentry taggedproduction.That is a silent failure with real cost: it pollutes production error rates with preview noise, and makes preview-only regressions invisible when filtering by environment. The server-side configs are unaffected —
sentry.server.config.tsandsentry.edge.config.tsuseVERCEL_ENV, which Vercel does set.Verify first
Check whether
NEXT_PUBLIC_VERCEL_ENVis actually set in the Vercel project across all three environments. It may already be configured, in which case this is only about preventing regression.Options
.env.schemaalready declares it@optional @public @type=enum(development, preview, production). Tightening to required in preview/production (@required=not(forEnv(development))) would fail the build when it is missing, instead of silently mislabelling. This is the fix the varlock adoption makes cheap.VERCEL_ENVin the schema (NEXT_PUBLIC_VERCEL_ENV=$VERCEL_ENV) so it cannot drift from the server-side value. Removes the manual project-settings step entirely.Option 2 is probably right — it eliminates the class of error rather than detecting it, and the two values should never legitimately disagree.
References
src/instrumentation-client.ts— the fallback expressionsrc/sentry.server.config.ts,src/sentry.edge.config.ts— server-side equivalents usingVERCEL_ENV.env.schema— both vars declared