feat: add typesafe client side env variables

[nramkissoon]

Add typesafe client side env variables

• I reviewed linter warnings + errors, resolved formatting, types and other issues related to my work
• The PR title follows the convention we established conventional-commit
• I performed a functional test on my final commit

---

Implements #195

Separates client and server env schemas. Also added an additional check to ensure client env variable names start with NEXT_PUBLIC_.

[juliusmarminge]

I would kind of like them to be part of the same env schema when they reach the developer. Example:

// client envschema
// define and export env schema

// server envschema
// define and export env schema

// env validator
// validate client
// validate server 
// merge and export validated env-vars

// usage
import { env } from "envpath";

const pusherKey = env.NEXT_PUBLIC_PUSHER_KEY; // begins with next_public so we know its client

const dbUrl = env.DATABASE_URL; // doesn't begin with next_public so we know its server

Or would this be confusing that you write the schemas in two separate files but import only a single?

[nramkissoon]

I would kind of like them to be part of the same env schema when they reach the developer. Example:

// client envschema
// define and export env schema

// server envschema
// define and export env schema

// env validator
// validate client
// validate server 
// merge and export validated env-vars

// usage
import { env } from "envpath";

const pusherKey = env.NEXT_PUBLIC_PUSHER_KEY; // begins with next_public so we know its client

const dbUrl = env.DATABASE_URL; // doesn't begin with next_public so we know its server

Or would this be confusing that you write the schemas in two separate files but import only a single?

I think merging the schemas makes sense for importing env vars server-side because both public and server-only should be available in that case. It would be cumbersome to have to import 2 different env files in a API route file, for example. I can make the changes to do this.

As for client only env vars, turns out you cannot destructure or dynamically access properties in process.env client side, so this validation does not work client side.

const _clientEnv = clientEnvSchema.safeParse(process.env);
export const env = _clientEnv

//usage
import {env} from "clientEnvPath"

// process.env is empty

We can still use this validation to verify env vars at build time and server-side along with the server env vars however, so no concerns there.

The user will either have to resort to accessing client-side env vars explicitly in process.env like process.env.NEXT_PUBLIC_foo or define and export an env object alongside the schema in order to get autocompletion like so:

// client-env-schema.mjs
import { z } from "zod";

export const envSchema = z.object({
  // Specify your environment variables schema here
  // Be sure to name your environment variables with the prefix "NEXT_PUBLIC_"
  NEXT_PUBLIC_foo: z.string(),
});

// client-env.mjs
import {envSchema} from 'client-env-schema.mjs'
export const env = envSchema.parse({
  NEXT_PUBLIC_DDDD: process.env.DDDD
})

//usage
import {env} from 'client-env.mjs'
...

I'd like some thoughts on which approach is better here.

[juliusmarminge]

My main concern is we will have 4 different files and it will be confusing what goes where, as well as there being 4 files + the actual .env seems kinda "bloated"?

[nramkissoon]

My main concern is we will have 4 different files and it will be confusing what goes where, as well as there being 4 files + the actual .env seems kinda "bloated"?

Spent some time playing with different approaches.

I could not find a way to validate both server and client variables in the same file while being able to import client-side.
Server variables don't show up in the browser so validation naturally breaks there. Wrapping the server var validation in a
if (typeof window === "undefined") will work on the client, but messes up the types on the server such that server vars will appear as string | undefined.

Instead, we can put both schemas in the same file so that the user only needs to edit a single file and reduce any confusion. Then, have a client-env.mjs and a server-env.mjs for validating and importing client and server env vars, respectively. server-env.mjs would have the merged client and server env vars.

So it would be 3 files under an env directory.

[juliusmarminge]

Spent some time playing with different approaches.

I could not find a way to validate both server and client variables in the same file while being able to import client-side. Server variables don't show up in the browser so validation naturally breaks there. Wrapping the server var validation in a if (typeof window === "undefined") will work on the client, but messes up the types on the server such that server vars will appear as string | undefined.

Instead, we can put both schemas in the same file so that the user only needs to edit a single file and reduce any confusion. Then, have a client-env.mjs and a server-env.mjs for validating and importing client and server env vars, respectively. server-env.mjs would have the merged client and server env vars.

So it would be 3 files under an env directory.

Yep. Came to the same conclusion. Let's see how that looks

[juliusmarminge]

Hotfixing some tRPC stuff so my bad for the format errors and stuff. Sorry, wanted to get the fix out asap

[juliusmarminge]

Add the "reverse" validation for server so that you can't "accidentally" expose secrets?

[nramkissoon]

Yea, also prevents typos and having to waste time figuring out why your public env vars aren't showing up in the browser.

[nexxeln]

Is this ready to be merged now?

[nramkissoon]

Is this ready to be merged now?

I think so. @juliusmarminge I've updated my changes to include what you have in your example https://github.com/juliusmarminge/trpc-rqv3

[juliusmarminge]

Looks good! Thanks for your patience :)