Shared variables from an extended config throw when used on the client

[GRA0007]

Say I have a common env config, and one specific to a Next.js site in my monorepo:

const common = createEnv({
  shared: {
    NODE_ENV: z.enum(['development', 'production', 'test']).default('development'),
  },
  experimental__runtimeEnv: {
    NODE_ENV: process.env.NODE_ENV,
  },
})

const siteEnv = createEnv({
  extends: [common],
  // Assume other variables here...
})

If I now try and use that shared NODE_ENV variable from my siteEnv config like siteEnv.NODE_ENV on the client side, t3-env will throw the Attempted to access a server-side environment variable on the client error, as I assume the proxy used to detect this doesn't take into account configs in the extends option when checking shared.shape:

t3-env/packages/core/src/index.ts

Lines 276 to 279 in 5975abe

	const isServerAccess = (prop: string) => {
	if (!opts.clientPrefix) return true;
	return !prop.startsWith(opts.clientPrefix) && !(prop in shared.shape);
	};

[ryanagillie]

+1 here, just ran into it today with the exact same configuration

[chertik77]

+1, but without extending

[yeuem1vannam]

I'm not sure this is the same behavior, but when uses extends with createEnv from env-next, a type error occurred when trying to

import { createEnv as coreCreateEnv  } from '@t3-oss/env-core'
import { createEnv as nextCreateEnv } from '@t3-oss/env-nextjs'
import { z } from 'zod'

// Shared environment variables created with env-core
export const sharedEnv = coreCreateEnv({
  clientPrefix: 'NEXT_PUBLIC_',
  server: {
    SERVER_VAR: z.string(),
  },
  client: {
    NEXT_PUBLIC_CORE_VAR: z.string(),
  },
  runtimeEnvStrict: {
    SERVER_VAR: process.env.SERVER_VAR,
    NEXT_PUBLIC_CORE_VAR: process.env.NEXT_PUBLIC_CORE_VAR,
  }
})

// Extending in env-nextjs has no problem if there is no new variable
export const nextEnv1 = nextCreateEnv({
  extends: [sharedEnv],
  runtimeEnv: {
    SERVER_VAR: process.env.SERVER_VAR,
    NEXT_PUBLIC_CORE_VAR: process.env.NEXT_PUBLIC_CORE_VAR,
  },
})

// There will be a problem if there is a new variable
export const nextEnv2 = nextCreateEnv({
  extends: [sharedEnv],
  client: {
    NEXT_PUBLIC_CLIENT_VAR: z.string(),
  },
  runtimeEnv: {
    SERVER_VAR: process.env.SERVER_VAR,
    NEXT_PUBLIC_CORE_VAR: process.env.NEXT_PUBLIC_CORE_VAR,
    NEXT_PUBLIC_CLIENT_VAR: process.env.NEXT_PUBLIC_CLIENT_VAR,
  },
})

// But if you want to use env-core, it works fine
export const coreEnv = coreCreateEnv({
  clientPrefix: 'NEXT_PUBLIC_',
  extends: [sharedEnv],
  client: {
    NEXT_PUBLIC_CLIENT_VAR: z.string(),
  },
  runtimeEnv: {
    SERVER_VAR: process.env.SERVER_VAR,
    NEXT_PUBLIC_CORE_VAR: process.env.NEXT_PUBLIC_CORE_VAR,
    NEXT_PUBLIC_CLIENT_VAR: process.env.NEXT_PUBLIC_CLIENT_VAR,
  },
})

The one created with createEnv from env-nextjs complains

Object literal may only specify known properties, and 'SERVER_VAR' does not exist in type 'Record<"NEXT_PUBLIC_CLIENT_VAR", string | number | boolean | undefined>'.ts(2353)
index.d.ts(10, 5): The expected type comes from property 'runtimeEnv' which is declared here on type 'Options<{}, { NEXT_PUBLIC_CLIENT_VAR: ZodString; }, {}, [Readonly<{ SERVER_VAR: string; NEXT_PUBLIC_CORE_VAR: string; }>]>'

while the one created by createEnv from env-core works normally

My workaround at the moment is switching to use @t3-oss/env-core with clientPrefix: 'NEXT_PUBLIC_'

P/S: I use

• "typescript": "5.5.4"
• "zod": "3.23.8"
• "@t3-oss/env-core": "0.11.1"
• "@t3-oss/env-nextjs": "0.11.1"
• "next": "14.2.5"