Configuratie op de juiste manier gebruiken

Introductie

Het configuratiesysteem van Laravel is ontworpen met een duidelijke regel: environment-variabelen zouden alleen in config-bestanden benaderd moeten worden, en applicatiecode zou altijd config() moeten gebruiken. Dit patroon zorgt ervoor dat het cachen van configuratie correct werkt en dat environment-checks betrouwbaar zijn. Daarnaast verbetert het gebruik van constanten en taalbestanden in plaats van hardcoded strings de onderhoudbaarheid.

Waarom

Compatibiliteit met caching: Directe env()-aanroepen geven null terug wanneer de config gecachet is, het gebruik van config() werkt altijd correct
Gecentraliseerde instellingen: Alle configuratie staat in config-bestanden, waardoor het eenvoudig is om te vinden en te controleren wat de applicatie gebruikt
Betrouwbare environment-checks: App::environment() en app()->isProduction() werken ongeacht het cachen van configuratie, in tegenstelling tot env('APP_ENV')
Veiligheid bij refactoren: Het gebruik van class-constanten in plaats van magische strings voor model-states en -types maakt refactoren in de IDE mogelijk en elimineert bugs door typefouten

Geschikt voor

Alle Laravel-applicaties
Applicaties die uitgerold worden met config:cache (oftewel de meeste productieomgevingen)
Projecten met meerdere omgevingen (local, staging, production)

Minder geschikt voor

N.v.t., deze praktijken zijn van toepassing op elke Laravel-applicatie

Voorbeelden

`env()` alleen in config-bestanden

// Slecht: geeft null terug wanneer de config gecachet is
$key = env('API_KEY');

// Goed: definieer in config, gebruik via config()
// config/services.php
'key' => env('API_KEY'),

// Applicatiecode
$key = config('services.key');

Gebruik `App::environment()` voor environment-checks

// Slecht: gaat stuk met config-caching
if (env('APP_ENV') === 'production') {

// Goed: altijd betrouwbaar
if (app()->isProduction()) {

// of
if (App::environment('production')) {

Gebruik constanten in plaats van magische strings

// Slecht: foutgevoelige magische string
return $this->type === 'normal';

// Goed: refactorbare constante
return $this->type === self::TYPE_NORMAL;

Gebruik taalbestanden wanneer ze al aanwezig zijn

Als de applicatie al taalbestanden gebruikt voor lokalisatie, gebruik dan ook __() voor strings die aan gebruikers getoond worden. Introduceer geen taalbestanden puur voor Engelstalige apps, eenvoudige string-literals volstaan daar prima:

// Alleen wanneer er al lang-bestanden in het project bestaan
return back()->with('message', __('app.article_added'));

Gebruik versleutelde env voor productiegeheimen

Sla productiegeheimen nooit op in platte .env-bestanden in versiebeheer:

php artisan env:encrypt --env=production --readable
php artisan env:decrypt --env=production

Geef bij cloud-deployments de voorkeur aan de native secret store van het platform (AWS Secrets Manager, Vault, enz.) en injecteer deze tijdens runtime.

Meer info

Use this skill when a Laravel task touches this best practice. It is self-contained so it can be installed independently by Laravel Boost or another agent-skill system. ## Core Guidance Laravel's configuration system is designed with a clear rule: environment variables should only be accessed in config files, and application code should always use `config()`. This pattern ensures that configuration caching works correctly and that environment checks are reliable. Additionally, using constants and language files instead of hardcoded strings improves maintainability. ## Why It Matters - **Caching compatibility**: Direct `env()` calls return `null` when config is cached, using `config()` always works correctly - **Centralized settings**: All configuration lives in config files, making it easy to find and audit what the application uses - **Reliable environment checks**: `App::environment()` and `app()->isProduction()` work regardless of config caching, unlike `env('APP_ENV')` - **Refactoring safety**: Using class constants instead of magic strings for model states and types makes IDE refactoring possible and eliminates typo-related bugs ## Apply When - All Laravel applications - Applications deployed with `config:cache` (i.e., most production environments) - Projects with multiple environments (local, staging, production) ## Be Careful When - N/A, these practices apply to every Laravel application ## Canonical Source - Full best practice: https://github.com/Dutch-Laravel-Foundation/best-practices/blob/main/project-structure-and-code-architecture/use-configuration-properly/BEST_PRACTICE.md - Dutch translation: https://github.com/Dutch-Laravel-Foundation/best-practices/blob/main/project-structure-and-code-architecture/use-configuration-properly/translations/nl.md ## Workflow 1. Inspect the user's Laravel code before recommending changes. 2. Identify the narrow rule from this best practice that applies to the task. 3. Prefer Laravel's built-in conventions and documented APIs over custom abstractions. 4. Keep examples focused on this practice; reference other skills or practices when the task crosses boundaries. 5. Verify code changes with the project's available tests, linters, static analysis, or framework checks. ## Review Checklist - The recommendation is Laravel-specific and grounded in this practice. - Code examples use realistic Laravel file names, class names, and method names. - The advice avoids mixing unrelated architecture, deployment, security, or testing topics. - Related practices are mentioned when useful, but not re-explained in full. - Dutch output, when requested, keeps framework and API names intact.