m1/env
m1/env extends Laravel's environment handling, letting you load and cascade multiple .env files so shared, environment-specific and local values stay separate across local, staging and production setups.
Architecture fit. m1/env is a single-purpose parser, not a configuration loader. Its contract is narrow: give it the raw contents of a .env file, get back a PHP array. It does not touch $_ENV, $_SERVER, putenv(), or any framework container. That is architecturally clean for a Laravel codebase because it cannot silently mutate process environment state — a common source of "works on my machine" bugs. It is a poor fit as a replacement for Laravel's built-in vlucas/phpdotenv bootstrap, and a good fit for the adjacent use cases: importing .env files produced by other systems, parsing tenant- or environment-specific config bundles, building migration/import tooling, or validating config files before deployment.
Integration feasibility. Low effort. Composer install, instantiate M1\Env\Parser with file contents, call getContent(), receive an associative array. No service provider, no config publishing, no facade required. The main feasibility gate is the Composer php constraint — the last tagged release is February 2020, so the package's supported PHP range likely predates PHP 8.1/8.2/8.3. Confirm installability on the target runtime before committing; if the constraint is restrictive, a fork with a widened constraint is trivial given the code surface.
Technical risk. Moderate, and concentrated in two areas. First, maintenance risk: no release in roughly five years, 61 stars, zero listed dependents, and a low composite score (1.69) that reflects staleness and adoption rather than functional defect. Second, semantic drift: m1/env's rules for quoting, escaping, export prefixes, comments, and ${VAR} interpolation will not match phpdotenv byte-for-byte. If both parsers ever read the same file in one system, values can diverge. Security exposure is low — it parses text and returns arrays, with no network, shell, or eval surface — but parsed output frequently contains secrets, so logging and exception handling need care.
Key questions.
composer.json constraint admit them unmodified?.env file be read by both m1/env and phpdotenv? If so, who owns semantic consistency?Stack fit. Use it as a library inside application code, never in the framework bootstrap. Laravel's phpdotenv integration should remain untouched. The natural placement is a thin adapter service — e.g. EnvFileImporter — that wraps Parser, applies schema validation, normalizes types (everything comes back as strings), and returns a typed DTO or validated array. Keeping the third-party class behind an interface means a future swap to phpdotenv's Dotenv\Parser or a hand-rolled parser is a one-file change.
Migration path. There is no migration from anything; this is additive. The realistic path is: introduce the wrapper for a specific bounded use case (importing externally supplied .env files, or config-diff tooling), prove it against real files, then expand. Do not present it as a phpdotenv replacement in any design doc — the missing putenv/$_ENV behavior makes that a rewrite, not a swap.
Compatibility. Two axes to verify before merge: PHP runtime constraint (Composer require), and parsing semantics against the corpus of real .env files you intend to feed it. Build a fixture suite from actual production-shaped files — quoted values with spaces, # inside values, empty values, duplicate keys, ${VAR} references, CRLF line endings, UTF-8 BOM — and assert the array output matches expectations. This fixture suite is also the artifact that makes a fork safe to maintain.
Sequencing.
phpdotenv output; document every divergence.Maintenance. Effectively unmaintained upstream. Budget for owning the code: it is small enough (a parser plus a handful of support classes) that a fork is a realistic afternoon, not a liability. Track it as an internal dependency with a named owner rather than as a normal Composer package. Security advisories are unlikely to appear for it, which cuts both ways — low attack surface, but also no one watching.
Support. Community-only, no SLA, no responsive maintainer expected. Internal teams will route questions to whoever owns the adapter. Mitigate with the fixture suite and a short README section documenting intentional behavior and known divergences from phpdotenv.
Scaling. Parsing is linear in file size and negligible for typical .env files (kilobytes). It is not a hot-path concern unless someone parses per-request on a high-traffic endpoint. If per-tenant config is the use case, parse once at deploy/tenant-provisioning time and persist to the config cache or database — do not re-parse inside request handling. Watch memory only for pathologically large files, which .env files should never be.
Failure modes.
phpdotenv — the highest-risk failure, because it produces wrong values rather than errors.null-like values need explicit normalization before use in typed config.Ramp-up. Very low. One class, array output, no framework knowledge required; a mid-level engineer is productive in under an hour. The real ramp-up cost is the semantic-difference investigation, which is a day of careful fixture work and should be treated as the actual integration task rather than an afterthought.
How can I help you explore Laravel packages today?