Type proccess.env based off the available secrets in a notebook

[versecafe]

Based off secrets set in a notebook, add them to process.env type, this way proper warnings are given if a secret is not set but is used in the code

[benjreinhart]

Adding some more clarity here in case it's helpful:

Secrets now need to be explicitly enabled per Srcbook. We can use this information to instruct typescript what to expect in the global process.env. This adds some nice typing support and errors for env variables, e.g.:

You can imagine a user importing a srcbook that's expecting secrets. Once they import and dependencies are installed, they'll see type errors in the code cells that inform them env variables are missing.

[Sanjoy-droid]

@benjreinhart could you assign me on this issue I'd love to work on this

[versecafe]

@Sanjoy-droid Feel free to take a go at it, if you need help reach out to @benjreinhart @nichochar or me, here's a reference of how to generate the types nicely to some capacity, you can take other approaches as well since this is for a stricter setup where there are constraints around types, lengths, prefixes, etc but shows how to type override process.env.*

import { z } from "zod";

export const envSchema = z.object({
  NODE_ENV: z
    .enum(["development", "production", "test"])
    .default("development"),
  VERCEL_ENV: z
    .enum(["production", "preview", "development"])
    .default("development"),
  CRON_SECRET: z.string().length(32),
  DATABASE_URL: z.string(),
  DATABASE_HOST: z.string(),
  DATABASE_USER: z.string(),
  DATABASE_PASSWORD: z.string(),
  DATABASE_NAME: z.string(),
  SITE_URL: z.string().default("http://localhost:3000"),
  SITE_LOCATION: z.string().default("localhost"),
  GITHUB_CLIENT_ID: z.string(),
  GITHUB_CLIENT_SECRET: z.string(),
  UPSTASH_REDIS_REST_URL: z.string(),
  UPSTASH_REDIS_REST_TOKEN: z.string(),
});

export type Env = z.infer<typeof envSchema>;

declare global {
  // eslint-disable-next-line @typescript-eslint/no-namespace -- intentional global override of process.env.
  namespace NodeJS {
    interface ProcessEnv extends Env {}
  }
}

[Sanjoy-droid]

@versecafe when users imports srcbook that expects secrets but they are not set at global, I was able to get error/warn in console but not as type errors as @benjreinhart mentioned above.

Anyhow I am checking it out

[Sanjoy-droid]

Hi @versecafe

I wanted to let you know that I’ll be unassigning myself from this issue. I tried to work on it, but I wasn’t able to make progress. Thank you for giving me an opportunity to work on this , and I hope to contribute in the future!

[Lokendra-sinh]

@nichochar could you please assign this to me...after @Sanjoy-droid dropping it I took a stab at it and here are my findings.

@benjreinhart FYI

We can extend the ProcessEnv interface but the issue is...the index signature defined in the "ProcessEnv" interface.

interface ProcessEnv {
  [key: string]: string | undefined;
}

This property allows access to any random env/secret even if we extend it, not allowing typescript to catch type errors. Surely, we can override it...but then we're not sure how this will affect third -party libraries we might be using in our code.

I was able to get the type errors by overriding the index signature.

declare global {
  namespace NodeJS {
    // Completely redefine ProcessEnv without the index signature to make sure typescript throws type errors
    interface ProcessEnv {
      NODE_ENV: 'development' | 'production' | 'test';

      API_KEY: string;
      DB_PASSWORD: string;

    }
  }
}

export {};

index.ts:

@benjreinhart @versecafe would love to know your thoughts on this?

[Lokendra-sinh]

Hey @nichochar @versecafe. So I started working on the issue and here's my progress. I would really like to know the "smart way" and be proven wrong!

1. I created a static env.ts file with some dummy env secrets.
2. Inserted it under src so it's available during the compile time

3. Static processEnv.ts file just to test if it's working or not

Based on the secrets in the srcbook, we have to dynamically generate the processEnv.ts file to make sure typescript's language service has access to all the latest environment variables.

[Sanjoy-droid]

is this issue fixed? then shouldn't it be closed?