Env Laravel Package

Product Decisions This Supports

• Build vs. buy for a config-access shim. The package is a thin, dependency-light function layer (Psl\Env\get_var(), set_var(), unset_var(), current_dir(), chdir(), plus path helpers) that replaces hand-rolled getenv()/$_ENV wrappers. The decision it informs: stop letting each team write its own escape hatch, adopt one.
• Standardizing across a mixed PHP estate. The real payoff is in code that runs outside the Laravel request cycle — artisan commands, queue workers, deploy scripts, Composer packages, and shared libraries that may be consumed by Symfony or plain-PHP services. That's where config() isn't available and getenv() sprawl accumulates.
• Portability of path/CWD handling. Working-directory and path operations are where code silently breaks between local, container, and CI environments. Centralizing them makes cron jobs, file-generation tasks, and CLI tooling behave consistently across platforms.
• Roadmap hygiene for shared packages. If you maintain internal PHP packages meant to work in and out of Laravel, adopting the broader php-standard-library surface is a defensible "foundation layer" bet — but scope it to the helper layer, not to configuration management.
• Not a decision this should drive: configuration architecture. It does not load .env files, cache config, validate schemas, or manage secrets. Do not let it be positioned as a replacement for config(), vlucas/phpdotenv, or a secrets manager — that framing will fail in review.
• Explicitly out of scope for a pricing/roadmap bet: the package itself shows 0 stars and 0 dependents and its README is a stub pointing at the monorepo. Treat adoption as "vendor a small utility surface you could replace in a day," not as a strategic platform commitment.

When to Consider This Package

Adopt if:

• You have non-Laravel PHP in the estate (CLI tools, workers, shared packages, Symfony services) and want one consistent env/CWD/path API.
• You are consolidating ad-hoc getenv()/$_ENV usage and want a mechanical, low-risk replacement with a stable namespace.
• You want a zero-dependency, MIT-licensed helper layer with no framework coupling and no ServiceProvider to maintain.
• You need path and working-directory utilities more than config loading, and you're fine pairing it with phpdotenv for .env parsing.
• You are already using or evaluating php-standard-library elsewhere and want internal consistency.

Look elsewhere if:

• Your app is Laravel-only. config() (cached, testable) plus framework env() covers this; adding a second access path creates two ways to do one thing.
• You need typed/validated config — casting "true", "1", "yes" to bool, required-vs-optional rules, nested schema. That's phpdotenv + symfony/validator or typed config objects. This package gives uniform access, not validation; casting stays your job.
• You need secret management, encryption, or remote loaders (Vault, SSM, K8s ConfigMaps as first-class sources).
• You require maintenance confidence — 0 stars, 0 dependents, thin release notes, and a stub README are real signals. If your org's dependency policy requires active community support, this fails review regardless of code quality.
• You need cached config in hot paths. Reading env on every request is the wrong tool for high-throughput endpoints.

How to Pitch It (Stakeholders)

For executives: We have PHP code that runs outside the web request — queue workers, scheduled jobs, deploy scripts, and internal packages — where environment and path handling is inconsistent and quietly fragile. This is a small, MIT-licensed, zero-dependency helper that gives those places one predictable API. It's a modest scope: a few days of migration in one service, no licensing cost, no framework lock-in, and trivially reversible. It is not a config platform — I'm deliberately not selling it as one.

For engineering: This is a drop-in, namespaced replacement for scattered getenv(), chdir(), and manual path string-building — uniform across Laravel, Symfony, and plain PHP. It sits alongside config() and phpdotenv, not on top of them: keep config() for app configuration, use this in CLI, jobs, and shared packages. Two honest caveats: it does not validate or cast values ("false" still needs handling on your side), and the upstream project has minimal adoption signals, so we pin the version and treat the surface as small and replaceable. Pilot it in one worker or CLI tool, measure, then decide on wider rollout.

For developers: One import, no globals, no === 'true' guesswork about where the value came from. Env\get_var('KEY', 'default'), Env\current_dir(), and path helpers that behave the same on macOS, Linux, and in CI. Replaces the boilerplate you've copy-pasted into three repos. Keep your existing .env loading — this reads the environment, it doesn't populate it.