Developer toolingeasy

envcheck: a .env linter and diff tool

A developer tool that lints .env files with line numbers and reports drift against .env.example, never printing secrets.

Suggested effort
~2.5h focused work
Window
24 hours
Starts from
An empty repo
Stack
Your choice
Sign in to start this build →

Opens in a new tab. The clock starts when you press Start inside the environment, not before, and your workspace is kept while you step away.

Time window 24 hours. Suggested effort about 2 to 3 hours.

Context

Half the team's "works on my machine" bugs are a missing or malformed environment variable. Build a small developer tool that validates .env files against a committed example and spots drift.

Core requirements

  • envcheck lint FILE reports problems with line numbers: duplicate keys, invalid key names ([A-Z_][A-Z0-9_]*), unquoted values with spaces, unterminated quotes, trailing whitespace, empty values.
  • envcheck diff .env.example .env lists keys missing from .env and keys present in .env but not in the example.
  • Support comments, blank lines, export KEY=value, single and double quotes, and # inside quoted values.
  • --format text|json output.
  • Never print secret values: output shows keys and line numbers only.

Acceptance criteria

  • Exit code 0 when clean, 1 when problems were found, 2 on usage or file errors.
  • Commit a fixtures/ folder with good and bad files; the README shows the output for each.
  • The parser is a separate module with unit tests that cover every rule above, including the quoting edge cases.
  • A test proves that no value from the input ever appears in the output.

Stretch goals (optional)

  • A schema file (envcheck.json) declaring types (int, url, bool, enum) and required keys, validated by envcheck validate.
  • --fix for the safe rules (trailing whitespace, sorting).
  • A pre-commit hook example.

Constraints

  • Any language. Suggested: Node (TypeScript), Python or Go.
  • No network access needed or used.

Deliverables (every project)

  • Source code committed in this repository (the grader diffs against the first commit).
  • README.md that replaces the stub, with: how to install, run and test it (copy-pasteable commands); the decisions and trade-offs you made; what you would do next with more time; and a short note on how you used the AI agent (what you delegated, what you checked or rewrote).
  • Automated tests that run with a single command (npm test, pytest, go test ./... or cargo test).
  • No secrets in the repository. Anything configurable reads from environment variables with safe defaults.

Ground rules

  • The 24-hour clock is a window, not a workload. Stop at roughly the suggested effort, then write down what you would do next. A small, finished, tested core beats a large unfinished one.
  • Use the AI agent as much or as little as you like: every prompt is recorded and the report shows how it was used. You are judged on the result and on whether you understood and verified what the agent produced.
  • The work is yours. PraxisAI uses it only to produce your assessment report.