Separate config proposal for modules => [...]

[pusachev]

Problem

Difficult control changes by git in config.php after add or delete modules

Solution

put modules => [..] config in a separate file

Requested Reviewers

@paliarush

[magento-cicd2]

All committers have signed the CLA.

[navarr]

Module enablement status should probably remain shared. Order.. I'm not aware of anyone that doesn't use the auto-generated order, except to avoid conflicts.

[pusachev]

@navarr thank's for answer.

You can tracked modules.php file if needed. About ordered, as I remember we used sequence for control ordered modules.

Best Regards, Pavel

[hostep]

Is there something in the deployment steps which relies on the sort order of modules? I'm talking about:

• bin/magento setup:di:compile
• bin/magento setup:static-content:deploy

If one of these commands reacts differently based on the sort order of modules, it's not a good idea to keep it out of the version control. Because running setup:upgrade tends to happen as a last step in the deployment process and if only then the sort order is recalculated, it might be too late? Unless a new bin/magento command is then also created which can generate these sort order first so we can then run that before we run those other commands.

I'm certainly not opposed to this change request, but with Magento 2.3.2 the sort order of modules changes much less aggressively then older Magento versions, so is this still something we need to worry about this much after Magento 2.3.2?

[pusachev]

Hi @hostep thank's for answer. I try explain.

When I start working on big project;

• State when we start development. We have one one state of modules => [];
• Then we start development and add new module -> then we have second state of modules => []
• Then we add new module by vendor and we have third state of modules => [] ...

When I add new module in project I'm not change modules => [] manually. For ordered I used sequence and magento generate orders automatically.

When I add new module I don't need track modules => [] changes because they generate in server automatically by setup:upgrade command

Best Regards, Pavel

[buskamuza]

Is there something in the deployment steps which relies on the sort order of modules?

Yes, both commands depend on the order. Order of modules impacts order of config and view files in which they're read by Magento application (including deployment tools). Those files include any XML files (DB schema, special config files, di.xml, layouts).

[Vinai]

I've only encountered issues with app/etc/config.php when different developers or teams merge their new modules into the main branch. That's when merge conflicts are common. Thankfully they are easy to resolve, so they are only a bit annoying. A separate modules.php wouldn't improve the situation though.

Sometimes there are modules that are only used in dev, but should not be active on integration or production. That used to be an issue, but now we have those modules deactivated in app/etc/config.php and override that in app/etc/env.php in dev only. Since this file is environment specific anyway that works very well (thanks to @danslo for pointing out that approach). Maybe that is a solution to the issue you are experiencing?

[pusachev]

Hi @Vinai thank's for you comment.

The situation from my side

1. Yes I know that env.php is merged with config.php and has priority.
2. I have a big project and 2 different teams(work remote). What I need do when I working or do code review? a) Change branch. b) Start command setup:upgrade, setup:di:compile, setup:static-content:deploy for chek that changes not broken deployment or migration scripts and functionality are working c) optionality make some changes in branch

Then if I create commit I need manually remove config.php from commit because it contained config data for different websites and stores but I not needed commit data from modules. If I change branch I need create stash because I can't change branch while config.php are changed. If module changes(add new modules) and we had conflict it's seems like merge hell.

For me add separate file is help me, because on my project we using cloud and deployment tools and I not needed check module order. And I can add it to .gitignore If we need disabled module we can do it from config.php,

How I see how it works.

File module.php cintains infornation only for modules and has low priority with array merge

File config.php contain information for system config, websites, stores and optionality contains data from module.php and can add manually(this can be used by disabled modules or manually sorting). This file can high priority then modules.php

File env.php contain locally config data and has higher priority than config.php and modules.php

Thank's

[Vinai]

@pusachev Seems I miss understood the proposal at first then. Now I think it is about separating the modules load order and state from the config,
not about the module load order from the enabled state. Thanks for clarifying. You have convinced me, separating the module load order and state from the other configuration makes sense.

PS: In the markdown in the PR, there needs to be a space between the headline hash characters and the word so github renders it properly, e.g. ### Problem instead of ###Problem.

[pusachev]

@pusachev Seems I miss understood the proposal at first then. Now I think it is about separating the modules load order and state from the config, not about the module load order from the enabled state. Thanks for clarifying. You have convinced me, separating the module load order and state from the other configuration makes sense.

PS: In the markdown in the PR, there needs to be a space between the headline hash characters and the word so github renders it properly, e.g. ### Problem instead of ###Problem.

Thank's. Updated PR.