Install Magento 2.1.0 using composer but use the --no-dev flag
Look at the dev/ directory in the filesystem
The dev/ directory should be empty or non-existing
The dev/ directory exists and contains a bunch of development stuff
In an effort to try to find the best options of deploying a Magento 2 installation to a production server, I keep discovering issues which aren't ideal.
As a best practise, we use composer install --no-dev --prefer-dist --optimize-autoloader on a production server when deploying. I would expect that no development dependencies gets installed because of this, but this is not true.
This isn't only about the /dev directory, but also for example about the lib/web/css/docs/ directory.
The last one for example causes the setup:static-content:deploy command to compile a less file which has absolutely no purpose of existing on a production server while it takes multiple seconds to compile this file, per locale, per theme.
In a very quick test, I discovered that when removing the above directories before executing setup:di:compile and setup:static-content:deploy makes those two run about 58 seconds faster (on my local machine) then without removing those directories.
Here is a list of files/directories which I believe shouldn't get deployed to a production server:
(the license files, I'm not sure about)
I think most of these files are getting into place because of the mapping in the composer.json file of the magento2-base module.
It would be great if those mappings can get split of into a mapping for development purposes and one for all environments.
My suggestion would be to add a map-dev to the extra section in the composer.json similar as the normal map section and update the magento-composer-installer project to support this and only install the map-dev files when you run composer without the --no-dev flag.
This is all theoretically, I haven't tested this properly, but let me know what you think.
I know that in your deploy scripts, you can simply delete the files you don't want after composer install --no-dev has run, but I think it makes sense to automate this, because not everyone will notice these issues.