Weave Code
Env Laravel Package
php-standard-library/env
Tiny PHP utility for reading environment variables with sensible defaults and type casting. Helps centralize access to config via env(), supports required keys, fallback values, and safe handling when variables are missing or empty.
Functions for inspecting and modifying environment variables, working directory, and paths
Frequently asked questions about Env
- Can I use this package in Laravel CLI commands or queue workers where Laravel’s env() helper isn’t available?
- Yes, this package is designed for non-web Laravel layers. It provides type-safe alternatives like `envBool()`, `envInt()`, and `envString()` that work in Artisan commands, queue jobs, and console scripts where Laravel’s `env()` helper isn’t loaded.
- How does this compare to Laravel’s built-in `env()` helper? Does it replace it?
- This package complements Laravel’s `env()` by adding type safety and consistency for non-web contexts. It won’t replace Laravel’s helper in web requests but excels in CLI, queues, or shared libraries where Laravel’s environment loading isn’t available.
- Will this work with Laravel’s cached configuration (config/cached.php)?
- No, this package reads environment variables directly (like `getenv()`) and doesn’t integrate with Laravel’s cached configuration. For web layers, stick with `config()` or `env()`; this is for dynamic or non-web environments.
- How do I handle missing or empty environment variables with fallback values?
- Use the package’s methods with defaults: `envString('DB_HOST', 'localhost')` will return `'localhost'` if `DB_HOST` is missing or empty. For required keys, omit the default and handle exceptions or use `envString('KEY', null, true)` to enforce presence.
- Does this package support Laravel’s `.env` file scanning automatically?
- No, you’ll need to load `.env` manually (e.g., with `vlucas/phpdotenv`) before using this package. In Laravel, this is only needed for non-web contexts where the framework doesn’t auto-load `.env` files.
- Can I use this in a Laravel microservice or shared library that isn’t part of a Laravel app?
- Absolutely. The package is framework-agnostic and works in plain PHP, Symfony, or any PSR-compliant project. It’s ideal for shared libraries or microservices where you need consistent environment variable access across multiple projects.
- How does type safety work for booleans? Will `envBool('FEATURE_FLAG', false)` accept strings like 'yes' or '1'?
- Yes, `envBool()` accepts common boolean strings (`'true'`, `'1'`, `'yes'`) as true and `'false'`, `'0'`, `'no'` as false. However, for strict validation, combine it with custom rules or use `envString()` followed by manual parsing if you need exact control.
- Is there a performance impact for high-frequency CLI tools (e.g., cron jobs)?
- The package is lightweight, but repeated calls to parse environment variables may add micro-overhead. For performance-critical cron jobs, cache results or pre-load variables into a service container. Avoid calling `env*()` in tight loops.
- How do I mock environment variables in PHPUnit tests?
- Use the package’s methods with test overrides: `envString('TEST_KEY', 'value', true)` forces a value for testing. For broader mocking, override `$_ENV` or `$_SERVER` globally in your test setup or use a testing library like `phpunit/phpunit` with environment overrides.
- What’s the best way to migrate from `getenv()` or `$_ENV` to this package?
- Start by replacing `getenv('KEY')` with `envString('KEY')` in non-web layers. Use `git grep` to audit usage, then gradually update to typed methods (`envInt()`, `envBool()`). For legacy code, create a facade or alias to ease the transition.
Weaver
How can I help you explore Laravel packages today?