Don't require client fields

[OmgImAlexis]

Would be nice if we're just using this for the server if we didn't need to pass in client and clientPrefix.

import { createEnv } from "@t3-oss/env-core";
import { z } from "zod";

export const env = createEnv({
    server: {
        DATABASE_URL: z.string().url(),
        OPEN_AI_API_KEY: z.string().min(1),
    },
    client: {}, // this is needed even if it's not used
    clientPrefix: 'client_',  // this is needed even if it's not used
    runtimeEnv: process.env,
});

[parnavh]

I think this would be a good idea, if we pass a separate flag like for example serverOnly: boolean, it would allow us to skip those config variables

I am willing to contribute if you need any help

[parnavh]

I am new to typescript, I have tried to implement this in my fork parnavh/t3-env. Can someone have a look and suggest ways to improve the implementation.

[henrikvtcodes]

100% second this. @parnavh I think you should just make a PR with that and see what happens. If the core maintainers don't want a server only option in the core package, somebody (am down to jump on this) should add an explainer in the docs and also discuss creating a second package like @t3-env/server that implements server only functionality.

[parnavh]

Sure, I'll work on adding the docs and possibly the clientOnly flag too as requested in #63. I was waiting for a green flag from the maintainers since it's not recommended to work on a feature without asking them first. @henrikvtcodes have you had time to look at the changes I made? Is there anything you think I should do differently?

[chungweileong94]

If you want to validate env only on server/client, t3-env is pure overhead for you, a simple zod validation is more than enough, like

const env = z.object({
    DATABASE_URL: z.string().url(),
    OPEN_AI_API_KEY: z.string().min(1),
}).parse(process.env);

t3-env is mainly for full-stack framework like NextJS, Nuxt & etc. And it was design to solve two things:

• Validate env with zod (and possibly other validators in future, feat: support more validation libraries #6)
  • However, if you only want to validate env on either server or client side, you can definitely (and recommend) validate your env with zod only, as I mentioned above.
• Throw error when you trying to access server env from client-side.

[parnavh]

I think this might hold true for server environments but we have additional functionalities for the client side like the prefix validation which might benefit client only environments.
I think that implementing this feature and request #63 could help this package be used in any environment even though that might not be the main use case. This would be useful when you can just throw this package into any application that requires environment variables and have the same implementation across multiple projects. What do you think about this? @chungweileong94

[chungweileong94]

This would be useful when you can just throw this package into any application that requires environment variables and have the same implementation across multiple projects

No offense, but I don't really encourage this tho, it usually a bad idea especially for people who are new to the dev industry, where trying to find a tool/package as a silver bullet for solving everything-sh is generally naive. t3-env is literally just adding server-client check on top of zod. In fact, the amount of code you need to write for t3-env versus zod-only approach is nearly identical, if you doesn't need the server-client checking, all you get from t3-env is more package size to download to your project.

[parnavh]

In fact, the amount of code you need to write for t3-env versus zod-only approach is nearly identical, if you doesn't need the server-client checking, all you get from t3-env is more package size to download to your project.

This is might hold true for server only approach where we don't have any client prefix, but we might benefit from this package in client only mode for the validation it provides with the client prefixes. I personally like the server/client only functionality and am ready to contribute and maintain the feature #64 if this is something that would be a good addition to the package. Let me know what you think

[OmgImAlexis]

@chungweileong94 open source is about being able to use software as we like. Adding this doesn't harm this project in any way at all and allows devs to use this across all their repos instead of just the ones using frontend.

What you're saying comes down to personal opinion.

Please see #64 (comment)

Also the "overhead" isn't really a good selling point for not having this when we're talking server side.

[chungweileong94]

@OmgImAlexis I completely understand, my point is that it's best for people who use this package to understand why this tool exists, to know what they are getting, that's it. I always encourage people to look into the OSS source code if they can, so they know how thing works, and if they really need it.

It just slightly bothers me when people use this tool on server-only project, where it's literally just a simple wrapper on top of zod.

My words could be a bit strong, but I didn't mean anything bad :)

[OmgImAlexis]

Yep... this tool exists to validate envs. How someone uses it is really up to the user.

It just slightly bothers me

This is personal preference and really shouldn't have any relevance here. If you don't want to use it this way you don't need to. 😄

[ThallesP]

Also, t3-env logging is a lot better than zod

Sure, we could do a better logging, but again would just add more overhead and not just a simple parse.