replaceConfigRecursivelyFrom has incorrect argument order causing published config to be ignored

[tansautn]

Laravel Version

12.29.0

PHP Version

8.3.23 (NTS)

Database Driver & Version

psql (PostgreSQL) 16.9 (Debian 16.9-1.pgdg110+1)

Description

The replaceConfigRecursivelyFrom method in Illuminate\Support\ServiceProvider has its arguments in the wrong order, causing published application configs to be overridden by vendor package defaults instead of the other way around.

Current Behavior

// Illuminate\Support\ServiceProvider line ~130
protected function replaceConfigRecursivelyFrom($path, $key)
{
    if (! ($this->app instanceof CachesConfiguration && $this->app->configurationIsCached())) {
        $config = $this->app->make('config');

        $config->set($key, array_replace_recursive(
            require $path,              // Package default config (position 1)
            $config->get($key, [])      // Published app config (position 2)
        ));
    }
}

According to PHP's array_replace_recursive documentation:

"When the value in the first array is scalar, it will be replaced by the value in the second array"

This means values from position 2 (app config) override position 1 (package config).

Real-world example:

// Package config (vendor/package/config.php)
return [
    'resources' => [
        'enabled' => true,
        'log_name' => 'Resource',
    ]
];

// Published app config (config/package.php) 
return [
    'resources' => [
        'enabled' => false,  // User wants to disable this
    ]
];

// Result after replaceConfigRecursivelyFrom:
[
    'resources' => [
        'enabled' => true,   // ❌ Still true! App config ignored
        'log_name' => 'Resource',
    ]
]

Expected Behavior

Published application config should ALWAYS take precedence over package defaults. The arguments should be swapped:

$config->set($key, array_replace_recursive(
    $config->get($key, []),     // Published app config (position 1)
    require $path               // Package default config (position 2)
));

The "Tire Replacement" Analogy

Imagine you go to a shop to replace your car tires:

• You bring new tires (your published config)
• The shop has old tires (package defaults)

Current behavior: The shop charges you for new tires but installs the old ones. That's what replaceConfigRecursivelyFrom does right now - it claims to "replace" but keeps the package defaults instead of your published overrides.

Expected behavior: Install YOUR new tires, keep the old ones as backup for missing parts.

Why This Matters

1. Breaking user expectations: When users publish and modify configs, they expect their changes to be respected
2. Inconsistent with Laravel patterns: config:publish suggests user configs should override package defaults
3. Silent failures: No error/warning when user configs are ignored, leading to confusion and wasted debugging time
4. Memory issues: Users may set conservative limits in published configs (e.g., batch sizes, cache TTLs) to prevent OOM errors, but these are silently ignored

Comparison with mergeConfigFrom

While mergeConfigFrom intentionally prioritizes package defaults (as confirmed in #12159), replaceConfigRecursivelyFrom is semantically different:

• merge = combine both, package provides defaults for missing keys
• replace = user config takes precedence, package fills gaps

The word "replace" in the method name implies user configs should win, not lose.

Proposed Fix

protected function replaceConfigRecursivelyFrom($path, $key)
{
    if (! ($this->app instanceof CachesConfiguration && $this->app->configurationIsCached())) {
        $config = $this->app->make('config');

        $config->set($key, array_replace_recursive(
            $config->get($key, []),     // App config first (wins on conflicts)
            require $path               // Package config second (fills gaps)
        ));
    }
}

Impact

This is a breaking change for packages currently relying on the buggy behavior. However:

• The current behavior contradicts the method's semantic meaning
• Users expect published configs to override vendor defaults
• Better to fix now in Laravel 12 than carry this bug forward

Steps To Reproduce

Steps to Reproduce

1. Create a package with config using replaceConfigRecursivelyFrom
2. Publish the config: php artisan vendor:publish
3. Modify a scalar value in published config (e.g., set enabled => false)
4. Observe that the package default value is used instead