Magento2: [2.1.7] Enabling module brakes sorting of modules in config.php

[ihor-sviziev]

We're keeping config.php file in git to make sure that only modules that we have enabled on local environment - will be enabled on production.

Preconditions

1. Magento 2.1.7
2. Remove app/etc/config.php file from .gitignore

Steps to reproduce

1. Install magento via web setup wizard
2. Commit file app/etc/config.php to git
3. Install module via composer composer require magepal/magento2-gmailsmtpapp:"^1.4"
4. Enable module via command line php -f bin/magento module:enable MagePal_GmailSmtpApp

Expected result

1. in app/etc/config.php we see that one line was added

Actual result

1. app/etc/config.php file has a lot changes

You can see following diff that I god after installing module in my gist.
It's really hard to understand what's changed, and during git merge we can broke something.
This issue reproducing with a lot another modules, I used specific one just to make it 100% reproducible.

I suggest to sort modules in config.php, it will prevent such issues.

[korostii]

You're quite right, but this issue has already been reported: see #8479.

[hostep]

Yes, I 100% agree with @ihor-sviziev!

We've been keeping the config.php file outside of our git repo's for Magento 2.0.x and 2.1.x projects, just because of this reordening of the modules. This keeps screwing every developer when switching branches and working on different modules and this causes merge conflicts all the time. Which is really annoying.
We keep it outside of our git repo, because Magento just regenerates it every time you run bin/magento setup:upgrade.

But now that Magento 2.2 will also put configuration data inside that file, we will need to include it in our git repo's and it's going to be a total mess :(
(This comment was based on incorrect documentation, which has been corrected recently: https://github.com/magento/devdocs/pull/1294)
(Update: comment above is still true apparently: https://community.magento.com/t5/Magento-DevBlog/Magento-2-2-Deployment-Improvements/ba-p/73119)

I would like to have this sort order of how the modules are supposed to be loaded to be stored in another file which we can ignore in our git repo's. That would be a better solution then how it is working currently I think.

[ihor-sviziev]

@magento-team @antonkril @okorshenko @maghamed is there any ideas why /app/etc/config.php is ignored in .gitignore?

I think it's ok for magento2 git repository (on github) because people use this repo for debugging, but it's not ok for magento2-base module.
I could try to fix this issue, but I may don't know the reason why it was did in this way.

[misha-kotov]

We arrived at the same conclusion. config.php in .gitignore could be good or bad depending on the type of development and associated flows. We need to consider core developers, SIs/partners, extension developers, and hobbyist installations. In addition, config.php will contain shared configuration data (intended to be shared across environments and therefore stored in VCS) needed for pipeline deployment starting in 2.2. Having considered various scenarios, we arrived at the following compromise:

1. We remove config.php from composer package .gitignore
2. We keep config.php in git repository .gitignore

[hostep]

@misha-kotov: any chance you could extract the sort order of modules into another generated file, which we can then ignore in source control to avoid merge conflicts? The list of modules in the config.php should then be completely alphabetical. This would probably solve the issue and feels like a good compromise. What do you think?

[orlangur]

extract the sort order of modules into another generated file

I vote for composer.lock :)

[hostep]

@orlangur: that's not going to work if you add modules specific for the project which aren't installed using composer :)

[orlangur]

@hostep yeah, I saw some custom modules not even having composer.json and I don't find it correct.

As to me, Composer shall be integrated as deep as possible, any module in /app/code/ shall be composer-packageable, any problem solvable without additional code must be solved this way (https://en.wikipedia.org/wiki/Occam%27s_razor).

Looks like https://getcomposer.org/doc/faqs/how-do-i-install-a-package-to-a-custom-path-for-my-framework.md should do the trick.

[hostep]

Even if a module does have a composer.json file, if the files are put manually in app/code there will be no reference in the main composer.lock file, since the module wasn't installed using composer.

Even if you would enforce all module to be installed using composer, it's not user friendly to develop modules in this way.

The only thing I can think of, that there is some kind of process which goes through all installed modules (composer installed or non-composer installed) and then generates a different composer.lock from all those, but even that is hard to do. I feel like composer is being abused too much for this purpose.

---

Why not just use the config cache to store the module sort order instead of in a file, I think Magento 1 also did it like this, might be a better/easier solution?

[magento-engcom-team]

Hi @ihor-sviziev
Thank you for your submission. We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues. Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

[adamzero1]

We had a similar issue, where the ordering of modules changing was causing us problems, this is the solution we came up with: <>

[orlangur]

@adamzero1 please propose changes creating a pull request instead of posting some patch links.