Running module:enable or module:disable on the server crushes the page

[norgeindian]

During our recent deployments we were facing the issue, that running bin/magento module:enable resp. bin/magento module:disable on the server after a deployer deployment crushes the whole page.
The error message said, that specific proxies could not be found and debugging a bit further we found out, that the generated folder was completely empty.
Checking #29 and magento/magento2#23251 we found out, that this is default Magento behavior to remove the generated folder for these commans. This happens in \Magento\Setup\Console\CompilerPreparation::handleCompilerEnvironment.
So obviously the problem is, that the folder is not properly regenerated again.
We used some approaches of the issues mentioned above and found out the following:

• Removing the generated folder from composer.json solves the issue
• running composer dump-autoload between deployment and bin/magento module:enable also solves the issue
• Running 'composer dump-autoload --optimize --apcu` (see Closes #40. Enhancement: Run Composer optimize autoloader after DI compile. #51) after deployment does NOT solve the issue

So it seems as if composer stops Magento from regenerating the generated folder somehow if these flags are set.
I assume that this happens because composer already throws the error before Magento is ready again.
Please be so kind and take a look at it. I hope this is generally reproducible. Maybe it makes sense to think again about #51

[osrecio]

To enable or disable modules you should redeploy. Is the safe way to do it.

[sprankhub]

@osrecio I agree in general. However, things do not always go as expected. Hence, it is rather important that bin/magento works correctly on the server as well. And unfortunately, it is currently broken due to the command composer dump-autoload --optimize --apcu. Errors not only happen if you run module:disable, but also for other commands like setup:upgrade.