If I use this pkg with nextjs and next public envs will it include zod in my client bundle?

[Oudwins]

as per title.

[juliusmarminge]

Yes you can use valibot for a more lightweight alternative if bundle size is important

[Oudwins]

@juliusmarminge Do you think there is a world/merit to have a compiled option where this code runs exclusively during build and outputs a typed structure without requiring import of the validation library into the client bundle or parsing the variables at run time

[juliusmarminge]

This code starts at just 1450 bytes.

https://bundlejs.com/?q=valibot%2C%40t3-oss%2Fenv-nextjs&treeshake=%5B*%5D%2C%5B*%5D&text=%22export+const+env+%3D+createEnv%28%7B%5Cn++client%3A+%7B%5Cn++++NEXT_PUBLIC_FOO%3A+string%28%29%5Cn++%7D%5Cn%7D%29%22

[juliusmarminge]

• you already can make it 0 runtime if you don't rely on transforms etc:

// next.config.js (or whatever frameworks entrypoint)

import "~/env"; // validate on build

// env.js
export const env = ...

// module augment to strongly type process.env
declare global {
  namespace NodeJS {
    interface ProcessEnv extends typeof env {}
  }
}

Then in your client app just use process.env. Your framework (next in this example) will statically replace all the references to e.g. process.env.NEXT_PUBLIC_FOO with the value it has during build

[Oudwins]

I hadn't thought of that. Thats a very good point!

I figured out that it would be included in the client bundle a bit after posting this and just went with valibot instead (good to know that its the reasonable approach). Unfortunately I do have to rely on transforms and my .env file is quite large but you are right in suggesting that this is probably of very little impact. I was curious because I believe that is how svelte works, they compile the types and variables into a file

[juliusmarminge]

I wanna keep it simple and not having to rely on compilers