I built envlint after losing too much time to broken .env files

A small side project turned into one of those bugs that wastes an entire evening.

The app worked on one machine, failed on another, and the real issue was not in the code. One variable was missing from .env, another existed only in .env.example, and a few old keys were still hanging around even though the app no longer used them.

Nothing looked obviously broken until runtime.

That pattern kept repeating, so I built envlint.

What envlint Does

envlint is a small open-source CLI written in Go that scans a codebase for referenced environment variables and compares them against your env files.

The goal is simple: catch config drift early, before it turns into deployment issues, broken local setups, or slow debugging sessions.

Right now, it can detect:

• Variables referenced in code but missing from .env
• Variables defined in .env but never used
• Drift between .env and the example env file
• Duplicate keys in env files
• Whether .env is ignored by .gitignore

It currently scans:

• Go
• JavaScript
• TypeScript
• Python

Why I Made It

I kept running into the same class of problem:

• A teammate had a different local env setup
• A feature introduced a new variable but nobody added it to the example file
• An old variable stayed around forever because nothing enforced cleanup
• The app only failed once it actually tried to use the missing value

Most of these issues are simple, but they are annoying because they show up late.

I wanted a small tool that could point at a repo and say:

These are the env-related problems you should fix before this becomes a runtime bug.

Example

envlint --path ./my-project

Example output:

Missing vars
  - STRIPE_SECRET_KEY

Unused vars
  - LEGACY_FLAG

.env missing from .env.example
  - INTERNAL_API_TOKEN

Summary: 3 issues

Repo

GitHub: github.com/drawliin/envlint

Looking for Feedback

The project is still early, and I would like feedback from people who manage config-heavy projects.

In particular, I’d like to know:

• Where the current scan is too noisy
• Which env access patterns I should support next
• What would make this useful in CI or team workflows

If you try it on a real repo and it reports something wrong, that is probably the most useful feedback I can get.