Add generated code to the psr-0 autoloader section so when optimizing…

[hostep]

… the autoloader on a production environment the autoloader will find more classes in its classmap. This should result in fewer file_exists calls and might increase the performance a tiny bit.

Description

Hi!

This PR was triggered by some discussions over here: davidalger/capistrano-magento2#102

When you read the Magento documentation around performance best practices for deploying to a production environment, you'll see something like this:

Run the following command to preprocess and compile DI:
bin/magento setup:di:compile
After compilation completes, we recommend running the following command:
composer dump-autoload -o
This command allows Composer to rebuild the mapping to project files so that they load faster.

Since the docs mention you should dump the autoloader after certain php classes got autogenerated, you would assume that the autoloader classmap file (vendor/composer/autoload_classmap.php) should have a mapping of those generated classes.

But that isn't the case right now.

This PR fixes this.

This should - in theory - increase the autoloading performance ever so slightly on production environments, since the autoloader wouldn't have to go searching for files on the filesystem but would already find them in the classmap and wouldn't have to perform file_exists calls for those generated classes.

Watch out:

1. I haven't tested this out on a real project yet. This was only done after some debugging and tinkering and reading the vendor/composer/ClassLoader.php file and some research on the world wide web.
2. I'm not exactly sure if this should go into the "psr-4"or the "psr-0" or the "classmap" section of the "autoload" section in the composer.json file. It was already suggested to put it in the classmap section over here: Improve performances by improving composer autoload #9102 but I'm not sure after reading the composer documentation? It seems to work in all 3 sections while testing, but I've decided to put it in the already being used "psr-0" section for now.
3. If this gets approved, this change will also have to go into the meta package magento/project-community-edition of which the sources I can't seem to find on github (unless the composer.json file which comes with it is somehow build using the composer.json file of this project?)
4. If this gets approved, it wouldn't be a bad idea to put this in the release notes of whatever version this gets released in, since the composer.json file of already existing projects doesn't get updated automatically after upgrading to a newer version of Magento.
5. If this gets backported all the way down to Magento 2.1, the path should become var/generation/

Fixed Issues (if relevant)

None that I could find

Manual testing scenarios

1. Install Magento using composer
2. Run bin/magento setup:di:compile
3. Run composer dump-autoload -o
4. Take a look at the file vendor/composer/autoload_classmap.php and see if you can find a mapping to a file inside generated/code, you won't find any
5. Change your composer.json as in this PR
6. Run composer dump-autoload -o
7. Take a look at the file vendor/composer/autoload_classmap.php and see if you can find a mapping to a file inside generated/code, you will find some references

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds on Travis CI are green)

[hostep]

Already found one problem with this on a local development environment (but not sure if people will actually run into this):

• Install Magento
• Run composer dump-autoload -o
• Run bin/magento setup:upgrade, result:

Cache cleared successfully
File system cleanup:
/path/to/magento/installation/generated/code/Composer
/path/to/magento/installation/generated/code/Magento
/path/to/magento/installation/generated/code/Symfony
/path/to/magento/installation/pub/static/deployed_version.txt
/path/to/magento/installation/pub/static/frontend
/path/to/magento/installation/var/view_preprocessed/pub
Updating modules:
Class Magento\Framework\Code\Generator\CodeGeneratorInterface does not exist

The last command first clears all those generated classes, but then uses the autoloader to get such a class it just deleted, and then fails.

So it might be annoying for local environments to have this, but the solution is to not use an optimized autoloader on local environments. Not sure how many devs use an optimized autoloader during development.

So yeah, I don't know...

[orlangur]

@mslabko could you please take a look into this? I'm pretty sure it was considered during autoloader optimization efforts.

[davidalger]

Very curious to see what the final results are here. Thanks @hostep for chasing this down!

@orlangur One note here that I'll add…if this was considered during autoloader deployments and intentionally not done then the mention in devdocs telling folks to run the dump-autoload command after DI compilation is pointless and should be removed.

[orlangur]

@mslabko @kandy anyone please?)

[orlangur]

Hi @hostep, changes must be applied to 2.2-develop first: https://github.com/magento/magento2/blob/2.2-develop/composer.json#L244

Please create a separate PR mentioning me.

[hostep]

Hi @orlangur, as you requested: #16435

Just out of curiosity, all PR's should first be made against 2.2-develop from now on? (well until 2.3 is released I guess). I don't really like this as there is more chance that something might be forgotten to be forward ported that way. But if those are the new rules, I'll try to adhere to them :)

[orlangur]

@hostep,

all PR's should first be made against 2.2-develop from now on?

Yes, since 2.2-develop became a default branch.

I don't really like this as there is more chance that something might be forgotten to be forward ported that way

It's totally opposite actually :) Before such change people were not able to fix issues in latest stable version of Magento - as you remember, it was develop branch - which is quite counter-intuitive. Now first of all we make the most relevant version of Magento better, the one really running on prod, and only after that next-version-to-be-released is improved with forwardport. There is a tooling to assure everything is forwardported ;)

Regarding you question that generation was previously removed, I have no idea, let's wait for reply from Olga or @mslabko.

[sidolov]

@hostep , looks like we merged duplicate of this pull request recently: #17056, so, I'm closing this one as not relevant.
Thank you for the collaboration!

[hostep]

@sidolov : so it has been discussed with @buskamuza why in 64424bc#diff-b5d0ee8c97c7abd7e3fa29b9a27d1780 this was reverted?

I just want to be sure that nothing bad could happen by adding this again.
See: #16435 (comment)