@workingmodel/where-did-my-env-go

Audits your environment variables — finds what's missing, what's misnamed, and what's set but never actually read. Developed by Working Model.

where-did-my-env-go

Scanning: /Users/you/my-app
12 key(s) in .env.example, 84 source file(s) scanned

✖ [Missing] 2 required env var(s) not set in current environment: DATABASE_URL, JWT_SECRET
  → Set these in your .env file, shell profile, or deployment config. They have no default value in .env.example.

⚠ [Misnamed] "DATBASE_URL" is set but .env.example expects "DATABASE_URL" — possible typo.
  → Rename DATBASE_URL → DATABASE_URL in your environment, or update .env.example if the name changed.

⚠ [Undocumented] 3 env var(s) referenced in code but missing from .env.example: STRIPE_SECRET_KEY, RESEND_API_KEY, FEATURE_FLAGS_URL
  → Add these to .env.example so the next person deploying knows they exist.

ℹ [Set But Never Read] 1 env var(s) set but never referenced in source (84 files scanned): OLD_ANALYTICS_ID
  → Either remove them from your environment, or check if they're read by a dependency rather than your own code.

Summary: 2 errors, 2 warnings
Missing required env vars — your app will likely fail to start.

Install

npx @workingmodel/where-did-my-env-go

Or install globally:

npm install -g @workingmodel/where-did-my-env-go

Usage

Run in your project root:

where-did-my-env-go

Or point it at a specific directory:

where-did-my-env-go /path/to/my-app

Exits with code 1 if required env vars are missing — pipe-friendly for CI.

What It Checks

| Check | What it catches | |-------|----------------| | Missing | Keys in .env.example that aren't set in your current environment — errors for required (no default), warnings for optional (has default) | | Misnamed | Keys in your environment that are within edit-distance 2 of an expected key — catches DATABASE_URI when you meant DATABASE_URL | | Set But Never Read | Env vars set in your environment or .env that are never referenced via process.env.KEY in your source code | | Undocumented | Keys referenced in your source code that aren't in .env.example — the ones the next developer won't know to set |

How It Works

The tool reads .env.example as the canonical list of what your app needs, then cross-references three sources:

1. Your current process.env — what's actually set in the shell running the command
2. Your .env file — what you've set locally (if present)
3. Your source code — scans .ts, .tsx, .js, .jsx, .mjs, .cjs files for process.env.KEY references

The misnamed check uses Levenshtein distance — it finds keys in your environment that are one or two edits away from what .env.example expects.

Why This Exists

You've set the env vars. You know you've set them. The app still won't start. Somewhere between your .env.example, your local shell, your deployment config, and the three people who've touched this project in the last six months, something got renamed, dropped, or never documented in the first place.

This tool tells you exactly what's out of alignment — in the time it takes to run one command.

More tools from Working Model → workingmodel.co · npm @workingmodel