This hits close to home. I just spent two hours last week debugging a deploy that failed because someone added a new env var to the app but never updated .env.example. Classic.
The schema-first approach makes so much sense. We've been using zod for runtime validation of env vars (the t3-env pattern) but having it baked into the .env file itself with decorator comments is a much cleaner DX. No separate validation file to maintain.
Quick question — how does Varlock handle the case where you have different required vars per environment? Like a STRIPE_WEBHOOK_SECRET that's required in production but not in dev where you're using Stripe CLI? The @defaultRequired=infer annotation looks promising but I'm curious how granular that gets.
There are a few different ways to handle env specific stuff. You can have separate schema files per env if you like (which get auto-loaded based on currentEnv) or you can set whether a particular item is required for a specific env at the item level. That would look something like:
This hits close to home. I just spent two hours last week debugging a deploy that failed because someone added a new env var to the app but never updated .env.example. Classic.
The schema-first approach makes so much sense. We've been using zod for runtime validation of env vars (the t3-env pattern) but having it baked into the .env file itself with decorator comments is a much cleaner DX. No separate validation file to maintain.
Quick question — how does Varlock handle the case where you have different required vars per environment? Like a
STRIPE_WEBHOOK_SECRETthat's required in production but not in dev where you're using Stripe CLI? The@defaultRequired=inferannotation looks promising but I'm curious how granular that gets.Give it a go. It's really great! Hit up @philmillman from Varlock if you have questions.
There are a few different ways to handle env specific stuff. You can have separate schema files per env if you like (which get auto-loaded based on
currentEnv) or you can set whether a particular item is required for a specific env at the item level. That would look something like:More on that here: varlock.dev/guides/environments/.