Feature request from hostep, posted on GitHub Jun 26, 2016
--no-dev
flagdev/
directory in the filesystemdev/
directory should be empty or non-existingdev/
directory exists and contains a bunch of development stuffIn 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.
Slightly related issues: