Feature Request: Support for passing zod Schema instead of object

[shkreios]

Summary

This issue proposes an enhancement to the current configuration system by allowing the passing of complete Zod schemas, rather than just object structures. This feature aims to provide greater flexibility and precision in validating environment variables, especially in scenarios requiring conditional validations and multiple configurations.

Detailed Explanation

In applications, which deploy to many different environments, with different set of environment variables having more power over the validation process in terms of which env variables are needed together or which should not nether be used together.

Proposed Solution

From what I can tell, this should be as easy as adapting the types to require a ZodSchema instead of Record<any,ZodType>. The tricky part could be to get the ErrorMessage type working.

Example:

Take, for instance, an app that allows a different set of authentication providers. In such cases, it's crucial to ensure that correlated environment variables are collectively defined. For example, if GOOGLE_CLIENT_ID is provided, it's imperative that GOOGLE_CLIENT_SECRET is also present, and not just marked as optional.

Example schema

const GoogleAuthSchema = z.object({
  GOOGLE_CLIENT_ID: z.string(),
  GOOGLE_CLIENT_SECRET: z.string(),
});

const ResendSchema = z.object({
  RESEND_API_KEY: z.string(),
});

const ServerSchema = z
  .object({
    NODE_ENV: z.enum(["development", "test", "production"]).default("development"),
    NEXTAUTH_SECRET: process.env.NODE_ENV === "production" ? z.string() : z.string().optional(),
  })
  .and(z.union([GoogleAuthSchema, ResendSchema]));

Resulting env type

type ServerSchemaType = {
  NODE_ENV: "development" | "test" | "production";
  NEXTAUTH_SECRET?: string | undefined;
} & (
  | {
      GOOGLE_CLIENT_ID: string;
      GOOGLE_CLIENT_SECRET: string;
    }
  | {
      RESEND_API_KEY: string;
    }
);

[juliusmarminge]

duplicate of #169