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 - https://github.com/t3-oss/create-t3-turbo/issues/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

[nktnet1]

Thanks @cjkihl for your suggestion on pure packages + using factory methods!

I was able to combine this with a really nice suggestion from tyleralbee to make my own turborepo template.

It should also be noted that turborepo (vercel) also recommends using a separate .env for each application:

Using a .env file at the root of the repository is not recommended. Instead, we recommend placing your .env files into the packages where they're used. (source)

Will leave my repository here for reference

• https://github.com/nktnet1/rt-stack

Initially, I also had a @repo/env package (as seen in this tag), but that made things quite messy (e.g. some env variables needed to be made optional with defaults so that it doesn't throw errors on packages that don't use them).

[CarlosZiegler]

Wow this is really nice , thanks for sharing !!!

[CarlosZiegler]

Hey @nktnet1 , I created my own repo based on yours. https://github.com/CarlosZiegler/zt-stack

• Added some better-auth features look like orgs, invitation, etc
• Added email provider ( resend )
• Added ZOD instead a valibot :) ( sorry man )

This still work in progress :)

PS: Added your repo into my README as reference/ inspiration.