dotenv-linter is a free, open-source command-line tool, written in Rust, that
checks a single .env file against its own formatting rules. Its documentation lists
14 checks -- duplicated key, ending blank line, extra blank line, incorrect delimiter, key
without value, leading character, lowercase key, quote character, schema violation, space
character, substitution key, trailing whitespace, unordered key, and value without quotes -- and
it can automatically fix many of them. Every one of those checks looks inward, at the file's own
internal consistency. None of them open a source file, and none of them know whether a declared
variable is read by any code anywhere.
This tool checks a different pair of things entirely, and never looks at a file's own
formatting. It parses an .env.example file's declared variable names, scans source
code for process.env.FOO (JavaScript/TypeScript), os.getenv /
os.environ (Python), ENV[] (Ruby), and System.getenv
(Java) reads, and diffs the two lists -- naming every variable the code reads that the example
file never mentions, and, in --strict mode, every variable the example file
declares that nothing reads anymore. A perfectly tidy, alphabetised, consistently-quoted
.env.example that dotenv-linter would pass cleanly can still be missing three
variables the code reads; that gap is exactly what this tool is built to catch.
| What you are trying to do | Where to do it |
|---|---|
Catch duplicate keys, inconsistent quoting, unordered keys, or a key with no value in one .env file. |
dotenv-linter -- that is exactly its 14-check list, and it can auto-fix most of them. |
Find out whether .env.example's declared names actually match what the code reads. |
This tool -- dotenv-linter's checks never open a source file, so it cannot see this at all. |
Stop a new contributor's cp .env.example .env && npm start from crashing on a variable the example file forgot. |
This tool, wired into CI as a gate on the same PR that adds the read. |
| Work across JavaScript, Python, Ruby, and Java in one repo. | This tool's source scan covers all four; dotenv-linter's checks are language-agnostic because they never read source code in the first place. |
Keep an .env or .env.example file's own syntax clean before committing it. |
dotenv-linter -- this tool never checks formatting and would not notice a duplicate key. |
These compose rather than compete, and cost nothing to run together: dotenv-linter as a fast
pre-commit or CI step for the example file's own hygiene, and this tool's cli.mjs
in the same CI job checking that the file's contents still match the code. Neither one makes the
other redundant, and a repo that only runs one is only checking half the problem.
Most repos that care about this will want both, because they check different things. dotenv-linter is a fast, dependency-free command-line tool, written in Rust, that lints one .env file against 14 formatting rules -- duplicate keys, unordered keys, inconsistent quoting, trailing whitespace, a key without a value, and similar -- and can auto-fix many of them. It never looks at your application code. This tool does the opposite: it never checks an .env file's formatting at all, and instead diffs the variable names declared in .env.example against the process.env.FOO / os.getenv / ENV[] / System.getenv reads actually found in your source code across JavaScript, Python, Ruby, and Java, naming every variable the code reads that the example file never mentions. Run dotenv-linter to keep one file's syntax clean. Run this tool to catch the example file quietly falling behind the code that reads it -- the bug that crashes a new contributor's first cp .env.example .env.
No, and it is not trying to. dotenv-linter's 14 checks (duplicated key, unordered key, quote character, trailing whitespace, key without value, and so on) all look inward at one file's own formatting; none of them read your application source code or know whether a declared variable is used anywhere. This tool never checks formatting at all -- a perfectly tidy .env.example, sorted and quoted exactly right, can still be missing three variables the code reads, and this tool is the one that would catch that. They compose: a repo can run both in the same CI job and get two independent, non-overlapping checks for the price of two free tools.
No. This site is not affiliated with, endorsed by, or sponsored by the dotenv-linter project or its maintainers. dotenv-linter is named here only to describe what this tool is and is not, based on dotenv-linter's own public documentation; check its repository for what it currently supports.