Add PHP8.4+ strongly typed config objects

[jhavenz]

Hello Laravel team,

As time has gone on, I've seen how PHP frameworks have generally 'plugged in' newer PHP features, vs having these features become a foundational way of how the framework works. In most cases it's a lot of work, so I get it - 100%.
With everything going on at the intersection with AI, I wouldn't want to prepare a PR for this until knowing:
a) If it's even feasible
b) If so, what extent of it's features the Laravel team would be interested in

The Laravel config system has always been pretty loose with regards to types, from an application and a vendor standpoint.
Personally, I'm more of a source-diver than a documentation reader but I still find random config values that allow me to tweak this or that at times.

This idea introduces a 'strongly typed config objects'. For the most part, this idea speaks for itself, so here's some examples:

#[Config('app')]
class AppConfig {
    #[Env('APP_ENV', default: 'production')]
    private(set) string $environment;
    
    #[Env('APP_DEBUG', default: false)]
    private(set) bool $debug;
    
    // Environment checks using hooks
    public bool $isProduction {
        get => $this->environment === 'production';
    }
    
    public bool $isDevelopment {
        get => $this->environment === 'development';
    }
    
    public bool $isTesting {
        get => $this->environment === 'testing';
    }
    
    // Derived config values
    public string $logLevel {
        get => match($this->environment) {
            'testing' => 'info', 
            'staging' => 'warning',
            'production' => 'error',
            'development' => 'debug',
            default => 'info'
        };
    }
    
    public array $enabledFeatures {
        get => [
            'error_reporting' => $this->debug,
            'query_logging' => !$this->isProduction,
            'debug_toolbar' => $this->isDevelopment,
            'metrics_collection' => $this->isProduction
        ];
    }
    
    // ...
    
    public function __construct() {}
}

Additionally - and optionally - it'd be great to be able to inject these config objects into other config objects, e.g.

#[Config('cache')]
class CacheConfig {

    // injected by laravel
    #[Inject]
    private AppConfig $appConfig; 
    
    #[Inject]
    private(set) ?RedisCacheConfig $redis = null; 
    
    // other 'stores' ... 
    
    #[Env('CACHE_DRIVER', default: 'redis')]
    private(set) string $driver;
    
    #[Env('CACHE_HOST', default: 'localhost')]
    private(set) string $host;
    
    #[Env('CACHE_PORT', default: 6379)]
    private(set) int $port;
    
    // Uses injected dependencies
    public string $prefix {
        get => strtolower($this->appConfig->name) . '_' . $this->appConfig->environment . '_';
    }
    
    public int $defaultTtl {
        get => $this->appConfig->isProduction ? 3600 : 60;
    }
    
    public string $connectionString {
        get => match($this->driver) {
            'redis' => "redis://{$this->host}:{$this->port}",
            'memcached' => "memcached://{$this->host}:{$this->port}",
            default => throw new \InvalidArgumentException("Unsupported cache driver: {$this->driver}")
        };
    }
    
    // ...
    
    public function __construct() {}
}

This 2nd example introduces the #[Inject] attribute (likely using an optional arg that allows the developer to provide the named binding/tag, e.g. #[Inject('reports')]).
Personally, I've fleshed out this property injection system as a means of handling memory leaks with Laravel Octane, but this config system is a much better way to introduce the idea and be able to expand on it from there as a framework.

To explain a bit:

• The private (set) implies that these properties can be set after of the bootstrap period.
• The #[Env] attribute would mean that the framework is injecting those values. This also provides strongly typed/validated values.
• There wouldn't be any 'nested config' values as we currently know/understand them, only #[Inject]'d objects. This would allow the dev to have control of any/all levels of config if they need to customize.

Feedback welcome!

[HeathNaylor]

I think what Laravel currently has is good enough. The backwards incompatible changes on this would be very broad since packages ship with config files as arrays. We'd either have to have all of those package maintainers update all the packages or support both config paradigms moving forward. Additionally if you wanted to enforce typed configs you could already create a value object, bind it in the service provider, and just pull values from config() like spatie/laravel-data does.

Overall I don't think this is worth the effort, backwards incompatibility, and maintenance of all the existing packages.

[jhavenz]

Fair enough, appreciate the review