- How do I install phpexperts/laravel-env-polyfill?
- Install it with Composer using composer require phpexperts/laravel-env-polyfill. Because ecosystem adoption is very low, pin an explicit version rather than floating on a caret constraint. After install, confirm the package's autoload actually defines env() before you remove any existing configuration code. Run a short compatibility spike on one service first rather than rolling it out broadly.
- Does this package work with Laravel 5.8 or newer?
- No. The package is a backward-compatibility shim that restores Laravel's pre-5.8 env() behavior, so it targets non-Laravel PHP code and legacy applications. Laravel 5.8 and later ship their own env() helper, and loading the polyfill there risks a redeclaration conflict with no benefit. Use it only as a temporary bridge before upgrading to Laravel 5.8+ or replacing it with an internal config wrapper.
- Which PHP versions does laravel-env-polyfill support?
- The package does not publish a clear, tested PHP support matrix, and because it is derived from Laravel 5.7-era code it most likely targets PHP 7.1 through 7.4. PHP 8 support must be proven rather than assumed, especially around type coercion, nullable defaults, and dotenv parsing. Run your own PHP matrix in CI and pin the Composer version you validated. Treat any PHP upgrade as a change that requires re-verification.
- Does it automatically load the .env file or just define the env() helper?
- The package is described as providing both the env() helper and .env file loading, but the exact bootstrap behavior is not documented clearly enough to assume. Verify in a spike whether it auto-loads .env on autoload, requires an explicit loader call, or only reads variables already present in the process environment. Check precedence between real environment variables, .env values, and coded defaults. Document the behavior internally so every service bootstraps consistently.
- Which vlucas/phpdotenv version and parsing semantics does it use?
- The upstream README does not clearly state the phpdotenv version it depends on, so inspect composer.lock or run composer show to confirm what you actually installed. Parsing semantics matter for quoted values, inline comments, escaped characters, and variable interpolation, and these differ across phpdotenv major versions. Test the specific .env files your services use, including edge cases like empty values, nulls, and values containing spaces or hashes. Pin the resolved dependency so a transitive dotenv upgrade cannot silently change behavior.
- What license is laravel-env-polyfill released under?
- The repository's license is reported as NOASSERTION, meaning the terms are not clearly declared in a machine-readable form. Treat that as a release blocker until legal review confirms the actual terms, since the code likely derives from Laravel, which is MIT licensed. If the license cannot be confirmed, copy the small helper logic into an internal package instead of depending on upstream. Do not ship it to production before that review is complete.
- Will the global env() function conflict with Laravel or my existing helpers?
- The package defines a global env() function, which can collide with Laravel's own helper, test bootstrap files, or your own internal wrappers. Check whether it guards the declaration with function_exists() and inventory every existing env() and getenv() call in your codebase before enabling it. In a Laravel application you should never load it at all. For non-Laravel services, define precedence rules and keep the polyfill behind a feature-flagged bootstrap.
- How does env() handle type casting, defaults, and null values?
- Laravel's pre-5.8 env() special-cases certain string values, casting true and false to booleans, null to a real null, and empty to an empty string, while quoted strings are trimmed of quotes. The second argument is returned as the default when the key is missing. Confirm whether this polyfill caches values per process and how it behaves with an explicit null default. Write small assertions for each of these cases so upgrades cannot change them unnoticed.
- How should I test and run this polyfill in PHPUnit, CLI, and queue workers?
- Add a bootstrap smoke test that asserts env() exists and correctly reads a known key plus its default, and run it in every SAPI you deploy to, including web, CLI, and queue workers. Because values are process-local, restart workers after environment changes and be careful with opcache when .env contents change. Avoid mutating .env at runtime, since that is not how this shim is designed to be used. Keep the polyfill behind an internal wrapper so tests can swap the implementation later.
- Is the package actively maintained, and what are the alternatives?
- Signals point to low adoption and likely stale upstream maintenance, with very few stars and no listed dependents, so expect to own it yourself with no commercial SLA. The better long-term alternatives are upgrading to Laravel 5.8+ and using its native env() helper, calling vlucas/phpdotenv directly behind a small internal config wrapper, or building a typed configuration object. If legal review or PHP compatibility fails, vendor or fork the minimal helper logic into your own package. Plan an exit from the polyfill on day one rather than treating it as a platform dependency.