feat: make packages pure and only validate env's in apps

[amirfakhrullah]

Describe the feature you'd like to request

From the template, we're using t3-env validations separately in apps/nextjs and packages/auth. If I want to use the environment variables in packages/api then I need to set up t3-env validations separately for that workspace. This looks like a duplicated code and I think we should refactor it.

Describe the solution you'd like to see

I suggest to put the t3-env validations in packages/config or in a new workspace, then other workspaces like apps/nextjs, packages/db, packages/auth and packages/api can just import it whenever they want to use them.

Additional information

I would love to work on this if you guys agree to pick this up

Similar issue - #385

[cjkihl]

Hi! I was running into the same problem. There's indeed tedious to have env variable validation in multiple packages and if you want to use the same env variable in another package, you have to run validation again.

My question is: Why should packages/auth and packages/api have env variables in the first place? They are packages, not runnable applications. In the same way you download a package from npm, it will not read your .env file, instead you give it variables as parameters.

Personally, I would rather have packages more pure, and only have env variables in the expo and nextjs application. Then pass them on as parameters to other packages.

For Example in apps/nextjs/src/pages/api/trpc/[trpc].ts we can pass all config as parameters to a factory method:

Any suggestions or ideas @juliusmarminge ?

[juliusmarminge]

Personally, I would rather have packages more pure, and only have env variables in the expo and nextjs application. Then pass them on as parameters to other packages.

I'd like that too, however I'm not sure how to implement that in a nice way. Open for PRs!

I don't want a separate @acme/env package. Either the package itself validates what it needs, or we keep envs in the apps and only validate there

[dBianchii]

I thought about this as well while dealing with envs. I agree with @cjkihl that it is better if we only have env variables in the expo and nextjs applications.

[RobRoseKnows]

I've also ran into this issue replacing the @vercel/postgres package with a generic postgres package in Drizzle. I honestly think the best bet is creating an acme/env package, I'm curious as to why you're against it @juliusmarminge

[jancbeck]

wondering why packages/db doesn't validate env but packages/auth does @juliusmarminge