5 Composer Tips PHP Developers Should Know

Composer is a new generation of PHP dependency management tool. For its introduction and basic usage, you can read this "Introduction Tutorial to PHP Dependency Management Tool Composer". This article introduces five tips for using Composer, hoping to bring convenience to your PHP development.

1. Only update a single library

If you only want to update a specific library and don’t want to update all its dependencies, it’s simple:

composer update foo/bar

In addition, this trick can also be used to solve the "warning message problem". You must have seen warning messages like this:

Warning: The lock file is not up to date with the latest changes in composer.json, you may be getting outdated dependencies, run update to update them.

ru, what went wrong? Don't panic! If you edit composer.json, you should see something like this. For example, if you add or update details such as a library description, author, more parameters, or even just a space, it will change the md5sum of the file. Composer will then warn you that the hash value is different from the one recorded in composer.lock.

So what should we do? The update command can update the lock file, but if it only adds some descriptions, it should not update any libraries. In this case, just update nothing:

$ composer update nothing
Loading composer repositories with package information
Updating dependencies
Nothing to install or update Writing lock file
Generating autoload files

This way, Composer will not update the library, but it will update composer.lock. Note that nothing is not a keyword in the update command. There is just nothing this package causes. If you type foobar, the result is the same.

If the Composer version you are using is new enough, you can use the --lock option directly:

composer update --lock

2. Install the library without editing composer.json

You may feel that you need to modify composer every time you install a library .json is too troublesome, then you can use the require command directly.

composer require "foo/bar:1.0.0"

This method can also be used to quickly open a new project. The init command has the --require option, which can automatically write composer.json: (note that we use -n so that we don’t have to answer the question)

$ composer init --require=foo/bar:1.0.0 -n $ cat composer.json
{ "require": { "foo/bar": "1.0.0" }
}

3. Derivation is easy

During initialization, have you tried the create-project command? ?

composer create-project doctrine/orm path 2.2.0

This will automatically clone the repository and check out the specified version. This command is very convenient to use when cloning a library, as there is no need to search for the original URI.

4. Consider caching, give priority to dist packages

Composer from the past year will automatically archive the dist packages you downloaded. By default, the dist package is used for tagged versions, such as "symfony/symfony": "v2.1.4", or wildcards or version ranges, "2.1.*" or ">=2.2,<2.3- dev" (if you use stable as your minimum-stability.

dist package can also be used for branches such as dev-master, Github allows you to download the tarball of a certain git reference. To force the use of tarball, and Instead of cloning the source code, you can use the --prefer-dist option of install and update.

Here is an example (I used the --profile option to show the execution time):

$ composer init --require="twig/twig:1.*" -n --profile Memory usage: 3.94MB (peak: 4.08MB), time: 0s
$ composer install --profile Loading composer repositories with package information
Installing dependencies
  - Installing twig/twig (v1.12.2)
    Downloading: 100%
Writing lock file
Generating autoload files
Memory usage: 10.13MB (peak: 12.65MB), time: 4.71s
$ rm -rf vendor
$ composer install --profile Loading composer repositories with package information
Installing dependencies from lock file
  - Installing twig/twig (v1.12.2)
    Loading from cache Generating autoload files
Memory usage: 4.96MB (peak: 5.57MB), time: 0.45s

Here, twig/twig:1.12. The compressed package of 2 is saved in ~/.composer/cache/files/twig/twig/1.12.2.0-v1.12.2.zip. Use it directly when reinstalling the package

5. When considering modification, source code should be given priority

When you need to modify the library, cloning the source code is more convenient than downloading the package. You can use --prefer-source to force the selection of the cloned source code.

composer update symfony/yaml --prefer-source

Next you can modify the file:

composer status -v
You have changes in the following dependencies: /path/to/app/vendor/symfony/yaml/Symfony/Component/Yaml:
    M Dumper.php

When you try to update a When you modify the library, Composer will remind you and ask whether to abandon the modification:

$ composer update
Loading composer repositories with package information
Updating dependencies
  - Updating symfony/symfony v2.2.0 (v2.2.0- => v2.2.0)
    The package has modified files:
    M Dumper.php
    Discard changes [y,n,v,s,?]?

Prepare for the production environment

Finally, when deploying the code to the production environment, don’t forget to optimize automatic loading:

composer dump-autoload --optimize

You can also use --optimize-autoloader when installing the package. Without this option, you may see a 20% to 25% performance loss.