Allow Module Configs to Override Root Application Configs

[solomon-ochepa]

Summary:

This PR introduces a core enhancement to the registerConfig() logic. It ensures that configuration files within a module (e.g., modules/Blog/config/config.php or modules/Blog/config/blog.php) override Laravel's root application configs (e.g., config/blog.php) during registration.

Why This is Necessary:

The modular architecture encourages encapsulation of logic and behavior per domain (module). However, Laravel’s default mergeConfigFrom() merges shallowly and always prioritizes existing config values, meaning module-defined values are ignored if a root config already exists.

This directly contradicts the core idea of modularity - that a module should define and control its behavior without being limited by app-level configs.

By allowing module configs to override root configs, developers get:

• Predictable behavior across all modules.
• Clean overrides and centralization of domain logic.
• Better separation of concerns between global app config and module logic.

Before:

// config/blog.php
return [
    'comments' => false,
];

// Modules/Blog/config/blog.php
return [
    'comments' => true,
];

// config('blog.comments') === false

After:

// config('blog.comments') === true

Module config values now correctly override root config values.

[rsd]

Why is this necessary?

I am working on a deep merge of configuration keeping the top-level/root config values.

I believe this should work on the other way around.
A module's config should have default values. These default values can be final if the top-level config does not exists (no clash).
However, if after installing a module, you do not agree that these config values in the module are the correct one for you app, you replace them at the application top-level, without the need to edit the module's config file.

I am clearly missing some (maybe obvious) point.
Could you please elaborate it to me?

BTW, my plan is to have the other way around behavior as an alternative and not as a replacement of the current take.

thanks,
-rsd

[solomon-ochepa]

The shortest answer is, a module extends the behavior of the root app. Extends!

…

________________________________ From: Raul Dias ***@***.***> Sent: 22 September 2025 17:47 To: nWidart/laravel-modules ***@***.***> Cc: Solomon Ochepa ***@***.***>; Author ***@***.***> Subject: Re: [nWidart/laravel-modules] Allow Module Configs to Override Root Application Configs (PR #2053) [https://avatars.githubusercontent.com/u/197183?s=20&v=4]rsd left a comment (nWidart/laravel-modules#2053)<#2053 (comment)> Why is this necessary? I am working on a deep merge of configuration keeping the top-level/root config values. I believe this should work on the other way around. A module's config should have default values. These default values can be final if the top-level config does not exists (no clash). However, if after installing a module, you do not agree that these config values in the module are the correct one for you app, you replace them at the application top-level, without the need to edit the module's config file. I am clearly missing some (maybe obvious) point. Could you please elaborate it to me? BTW, my plan is to have the other way around behavior as an alternative and not as a replacement of the current take. thanks, -rsd — Reply to this email directly, view it on GitHub<#2053 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A2N5DSZFPO6OCGENAFHB35T3UAR37AVCNFSM6AAAAAB3RCPR3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRQGE2DQMRZGA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[rsd]

got it.
I might be using it wrong. Breaking a large app into smaller ones, so modules are reusable pieces.
However, the config does not fit all cases.
I am submit the PR to extend in this format too, in case it helps.