dragon-code/env-sync
Synchronize Laravel .env files with .env.example using Dragon Code Env Sync. It detects missing or outdated variables, updates environment files safely, and helps keep local, staging, and team configurations consistent. Run it locally or in CI to prevent config drift.
Architecture fit. dragon-code/env-sync is a single-purpose dev-time artisan utility: it reconciles the keys in a developer's .env against the canonical .env.example so new configuration added by a teammate doesn't silently fail on pull. That places it entirely outside the production runtime surface — no service provider logic on the request path, no migrations, no storage, no queue or event coupling. For a Laravel shop it is architecturally inert, which is its main virtue: adoption cannot destabilize the application. The corollary is that the value ceiling is low. It addresses onboarding friction and "undefined env key" bugs, not configuration management. Teams already running secrets through Vault, AWS Secrets Manager, or Kubernetes ConfigMaps get materially less from it, since .env.example is no longer the source of truth.
Integration feasibility. Mechanically trivial: composer require --dev, Laravel package auto-discovery, one command. Realistically a half-day including validation. Release 4.1.0 materially improves this picture: adding Symfony 7 support is the prerequisite for Laravel 11 compatibility, since Laravel 11 ships Symfony 7 components. That was the single most likely blocker in the prior assessment, and it now appears addressed at the transitive level. The gating question shifts from "is it dead?" to "did 4.1.0 also widen the first-party constraints?" — specifically illuminate/support and the PHP floor. Confirm the declared matrix rather than assuming the Symfony bump implies Laravel 11 support, and verify with composer why-not laravel/framework before committing. MIT licensing still makes vendoring the command into app/Console/Commands/ a clean fallback if any constraint remains tight.
Technical risk. The dominant risk was stewardship, and 4.1.0 is the first real counter-evidence: a maintainer-authored release within the current cycle, targeting a live framework generation. That moves the package from "archived" to "low-cadence but alive," which is a meaningful downgrade in risk — but one data point does not establish a maintenance cadence, and the low star/dependent count still means no community validation and no security response pipeline. Treat this as a stay of execution, not a clean bill of health. Secondary risk is unchanged and now the more prominent one: .env parsing fidelity. Dotenv formats tolerate quoted values, inline # characters, multiline blobs, and comments, and a naive line-based sync can mangle or duplicate them. Blast radius remains contained — .env is local and untracked, so a bad write costs a developer minutes, not an incident. The one scenario to explicitly forbid is auto-writing .env.example in CI, which converts a local annoyance into committed configuration drift.
Key questions.
illuminate/support and the PHP floor, or does it only bump the Symfony transitive dependency? This is the deciding question.Stack fit. Appropriate for a conventional Laravel monolith or a small team where .env.example is genuinely the contract for environment configuration. Add as require-dev only, and confirm it is excluded from production builds via composer install --no-dev. It coexists fine with Sail/Docker local development; its value degrades in direct proportion to how much configuration lives outside .env.
Migration path. The pin-and-guard route is now materially more attractive than it was: 4.1.0 gives us a version that plausibly resolves against a current Laravel stack, so pinning at an exact version and relying on CI to catch resolution breakage is a defensible default rather than a stopgap. Vendoring the command source under MIT attribution remains the lower-total-cost option and eliminates the composer-constraint tail risk entirely, but it is no longer the obvious choice it was when the package looked abandoned. Decide between them after the constraint check, not before. Migrating off either route later is cheap because there is nothing to unwind but one class and one command registration.
Compatibility. Build a small matrix test against every Laravel/PHP combination we support before rollout. 4.1.0 should move Laravel 11 into scope, but verify rather than infer — a Symfony 7 dependency does not guarantee the first-party illuminate/support constraint was widened. Watch specifically for Laravel 11+ skeleton changes (the reduced default .env.example, APP_KEY handling) and for PHP 8.3+ deprecation notices in the dependency tree. Treat a failing matrix as a stop signal, not a patch-and-move-on signal — patching a low-cadence package is a fork decision and should be made deliberately.
Sequencing.
composer.json diff: confirm the illuminate/support and PHP constraints, not just the Symfony entry..env.composer script alias so it is discoverable.Maintenance. The archived-status premise no longer holds, so the inherited-ownership estimate should be revised down: budget roughly half a day to one engineer-day per year rather than one to two, contingent on the maintainer continuing to absorb framework bumps. Keep the vendoring option warm as the hedge against a return to dormancy. MIT licensing makes the fork path legally unencumbered, and the small surface area makes it technically unencumbered too.
Support. Still no vendor and no meaningful community given the star count, but there is now evidence of an active maintainer. Internal ownership must still be explicit — name a team or individual — because a low-cadence package can lapse between releases without anyone noticing. Ramp-up for the owner is low (single command, readable source), but someone must be named and someone must watch the release feed.
Scaling. The tool itself scales without effort: it is a per-developer CLI with no infrastructure footprint, and it costs nothing at 5 engineers or 500. The problem it solves does not scale, however — as environments multiply and secrets move into managed stores, .env.example drift stops being the bottleneck and the package's value flattens.
Failure modes.
.env corruption — duplication, dropped keys, or mangled quoted values on non-idempotent runs; recoverable locally but erodes trust in the tool..env.example as authoritative when real configuration lives elsewhere, producing a green check that means nothing..env.example in a pipeline, drift becomes a committed artifact rather than a local inconvenience.Recommendation. Release 4.1.0 removes the strongest objection in the prior assessment: Symfony 7 support plausibly clears the Laravel 11 blocker, and a maintainer-authored release in the current cycle is real counter-evidence to the "archived and abandoned" characterization. That justifies revisiting the decision rather than defaulting to a rewrite. The revised call is conditional: if the composer.json diff widens illuminate/support and the PHP floor to our matrix, adopt as a pinned require-dev dependency with a named internal owner and a documented vendoring fallback. If it only bumps the Symfony transitive and leaves the first-party constraints stale, the original recommendation stands — replicate the behavior with a small in-house artisan command or vendor the MIT source. Either outcome delivers the same onboarding benefit; the underlying idea, a CI check that fails when .env.example drifts from the keys the application actually reads, is worth keeping regardless.
How can I help you explore Laravel packages today?