- What does romanzipp/laravel-env-normalizer do?
- It is a small, dev-only Laravel package that rewrites your .env file so its keys follow the order and structure of .env.example. It registers an Artisan command that parses both files and normalizes formatting so used and unused variables are easier to spot. It has no runtime footprint, no middleware, and no config publishing, so it only matters during local development and onboarding.
- How do I install laravel-env-normalizer?
- Install it as a dev dependency with composer require --dev romanzipp/laravel-env-normalizer, then run the Artisan command it registers. Package auto-discovery usually handles service provider registration, so no manual wiring is needed. Check that its illuminate/support and PHP constraints match your stack before installing.
- Does it support Laravel 9, 10, or 11?
- Probably not without a fork. The last release was October 2021 and the constraint set targets Laravel 8 and PHP 8.0, so Composer will likely block installation on Laravel 9, 10, or 11. Treat a fork or vendored copy as the expected path on a modern stack.
- Is it safe to run against a production .env file?
- No. This is a developer-experience utility that belongs in require-dev and should never run against a production .env or inside a deploy pipeline. It mutates the file in place, and the evaluation flags the absence of a documented atomic write or backup as a local-outage risk. Test on a disposable copy first.
- What happens to keys in .env that are not in .env.example?
- This is the most important behavior to verify in the source before adopting the package. A silent drop of a live variable would be disqualifying, so you need to know whether orphan keys are dropped, appended, or reported. Run it against a copy of your real .env and diff the output.
- Does it have a dry-run or check mode for CI?
- Verify this before relying on it, because a non-destructive verify/diff mode with an exit code is the most useful feature for CI. The evaluation could not confirm one exists, and in-place rewriting is not suitable for a pipeline. If you need CI checks, add a verify mode to your fork.
- Will it preserve comments, quoting, and ${VAR} interpolation?
- Do not assume byte-for-byte preservation. .env is a deceptively hard format, with quoted values, inline comments, a # inside quoted values, escaped quotes, multiline values, export prefixes, and ${VAR} interpolation, all of which break naive line-based parsers. Read the tokenizer and round-trip a copy of your real .env before trusting it, or delegate parsing to vlucas/phpdotenv.
- Is romanzipp/laravel-env-normalizer still maintained?
- Not actively. The last release was October 2021, it has a single maintainer, one star, and zero dependents, which also means no downstream bug discovery. It is better treated as a source of an idea than as a long-lived dependency.
- Should I depend on it or fork it into my own codebase?
- Forking is the recommended path. The MIT license and small surface make it practical to vendor roughly 200 lines into your own Artisan command under your namespace, hardened or backed by phpdotenv's parser. That removes supply-chain and upgrade exposure at a cost measured in hours, not sprints.
- Does it handle .env.testing and other environment-specific .env.* files?
- That is unclear from the public description, which only refers to .env and .env.example. The evaluation flags whether it follows include or environment-specific .env.* files such as .env.testing as an open question. Inspect the command's file resolution logic before assuming support.