Composer has the option to load several dependencies only while being in development, so the tools will not be installed in production (on the live server). This is (in theory) very handy for scripts that only make sense in development, like tests, fake-data-tools, debugger, etc.
The way to go is to add an additional require-dev
block with the tools you need in dev:
"require-dev": {
"codeception/codeception": "1.6.0.3"
}
and then (theoretically) load these dependencies via
composer install --dev
Composer has changed the behaviour of install
and update
dramatically in 2013, require-dev
-dependencies are now installed by default (!), feel free to create a composer.json with a require-dev
block and perform an composer install
to reproduce.
As the most accepted way to deploy is to push the composer.lock (that holds your current composer setup) and then do an composer install
on the production server, this will also install the development stuff.
What's the correct way to deploy this without installing the -dev dependencies ?
Note: I'm trying to create a canonical Q/A here to clarify the weird Composer deployment. Feel free to edit this question.
This question is related to
php
deployment
composer-php
On production servers I rename vendor
to vendor-<datetime>
, and during deployment will have two vendor dirs.
A HTTP cookie causes my system to choose the new vendor autoload.php
, and after testing I do a fully atomic/instant switch between them to disable the old vendor dir for all future requests, then I delete the previous dir a few days later.
This avoids any problem caused by filesystem caches I'm using in apache/php, and also allows any active PHP code to continue using the previous vendor dir.
Despite other answers recommending against it, I personally run composer install
on the server, since this is faster than rsync from my staging area (a VM on my laptop).
I use --no-dev --no-scripts --optimize-autoloader
. You should read the docs for each one to check if this is appropriate on your environment.
Now require-dev
is enabled by default, for local development you can do composer install
and composer update
without the --dev
option.
When you want to deploy to production, you'll need to make sure composer.lock
doesn't have any packages that came from require-dev
.
You can do this with
composer update --no-dev
Once you've tested locally with --no-dev
you can deploy everything to production and install based on the composer.lock
. You need the --no-dev
option again here, otherwise composer will say "The lock file does not contain require-dev information".
composer install --no-dev
Note: Be careful with anything that has the potential to introduce differences between dev and production! I generally try to avoid require-dev wherever possible, as including dev tools isn't a big overhead.
I think is better automate the process:
Add the composer.lock file in your git repository, make sure you use composer.phar install --no-dev when you release, but in you dev machine you could use any composer command without concerns, this will no go to production, the production will base its dependencies in the lock file.
On the server you checkout this specific version or label, and run all the tests before replace the app, if the tests pass you continue the deployment.
If the test depend on dev dependencies, as composer do not have a test scope dependency, a not much elegant solution could be run the test with the dev dependencies (composer.phar install), remove the vendor library, run composer.phar install --no-dev again, this will use cached dependencies so is faster. But that is a hack if you know the concept of scopes in other build tools
Automate this and forget the rest, go drink a beer :-)
PS.: As in the @Sven comment bellow, is not a good idea not checkout the composer.lock file, because this will make composer install work as composer update.
You could do that automation with http://deployer.org/ it is a simple tool.
My recommendation is to checkout the code on a deployment machine, install dependencies as needed (this includes NOT installing dev dependencies if the code goes to production), and then move all the files to the target machine.
Why?
composer install
Long story short: Use Composer in an environment you can control. Your development machine does qualify because you already have all the things that are needed to operate Composer.
What's the correct way to deploy this without installing the -dev dependencies?
The command to use is
composer install --no-dev
This will work in any environment, be it the production server itself, or a deployment machine, or the development machine that is supposed to do a last check to find whether any dev requirement is incorrectly used for the real software.
The command will not install, or actively uninstall, the dev requirements declared in the composer.lock file.
If you don't mind deploying development software components on a production server, running composer install
would do the same job, but simply increase the amount of bytes moved around, and also create a bigger autoloader declaration.
Source: Stackoverflow.com