This example demonstrates all validation tests that zenv can perform.
validator/
├── .env.example # Documented environment variables
├── test-env.config.json # Validator configuration
├── src/
│ ├── env.ts # Zod schema (correct pattern)
│ └── config.ts # Contains intentional violations
└── README.md
# From the repository root
./target/release/zenv validate examples/validator
# With custom config
./target/release/zenv validate -c examples/validator/test-env.config.json examples/validator
# Or from this directory
cd examples/validator
../../target/release/zenvThe validator will find several issues:
src/config.ts contains intentional process.env usage outside of env.ts:
- Line with
process.env.DEBUG - Line with
process.env.NODE_ENV - Line with
process.env.LEGACY_API_KEY
- Orphaned variable:
LEGACY_API_KEYis in.env.examplebut not in the Zod schema - Undocumented variable:
INTERNAL_API_KEYis in the Zod schema but not in.env.example
Change src/config.ts to use the validated env:
// Before (bad)
const debugMode = process.env.DEBUG === 'true';
// After (good)
import { env } from './env';
const debugMode = env.DEBUG;Either:
- Add
LEGACY_API_KEYto the Zod schema insrc/env.ts - Or remove it from
.env.exampleif no longer needed
Add INTERNAL_API_KEY to .env.example:
# Internal
INTERNAL_API_KEY=See test-env.config.json for how to:
- Enable/disable specific tests
- Exclude certain directories or files
- Allow specific generic variable names
- Exclude variables from specific checks