Composer.json: Project Installation

Basic usage

• Basic usage
  • Installation
  • composer.json: Project Installation
    • About require Key
    • Package Name
    • Package version
    • Next important version (tilde operator)
    • Stability
  • Install dependent packages
  • composer.lock-Lock file
  • Packagist
  • Auto Load

Installation

To install Composer, you only need to download the composer.phar executable file.

curl -sS https://getcomposer.org/installer | php

Please see the introductory section for details.

To check whether the Composer is working properly, you only need php to perform PHAR:

php composer.phar

This will return you to an executable list of commands.

Note: You can also only perform --check options without downloading Composer. For more information please use --help .

curl -sS https://getcomposer.org/installer | php -- --help

composer.json: Project Installation

To start using Composer in your project, you only need a composer.json file. This file contains the dependencies of the project and some other metadata.

This JSON format is very easy to write. It allows you to define nested structures.

About requireKey

The first thing (and often only one thing to do), you need to composer.json specify require the value of the key in the file. You simply need to tell Composer which packages your project needs to rely on.

{    "require": {        "monolog/monolog": "1.0.*"    }}

As you can see, you require need a package name (for example monolog/monolog ) to map to the object of the package version (for example 1.0.* ).

Package Name

The package name is comprised of the vendor name and its project name. It is usually easy to produce the same project name, and the presence of the vendor name solves the problem of naming conflicts well. It allows two different people to create json libraries of the same name, and then they will be named igorw/json and seldaek/json .

Here we need to introduce that the vendor name is the same as the monolog/monolog project name, and we recommend this for a project with a unique name. It also allows more related items to be added later in the same namespace. If you maintain a library, this will make it easy for you to separate it into smaller parts.

Package version

In the previous example, the Monolog version we introduced was specified as 1.0.* . This represents any 1.0 development branch from the beginning, it will match 1.0.0 , 1.0.2 or 1.0.20 .

Version constraints can be specified in several different ways.

name	Example	Description
The exact version number	1.0.2	You can specify the exact version of the package.
Range	>=1.0>=1.0,<2.0>=1.0,<1.1|>=1.2	You can specify a valid version range by using the comparison operator. Valid operators: > ,, >= , < <= ,, != . You can define multiple ranges, separated by commas, which will be treated as a logical and. A pipe symbol | is treated as a logical or . and has a higher precedence than OR.
Wildcard characters	1.0.*	You can use wildcard characters * to specify a pattern. 1.0.* >=1.0,<1.1 is equivalent to.
Assignment operators	~1.2	This is useful for projects that follow a semantic version number. ~1.2equivalent to >=1.2,<2.0 . To learn more, please read the next section.

Next important version (tilde operator)

~It is better to use examples to explain: ~1.2 equivalent >=1.2,<2.0 , but ~1.2.3 equivalent >=1.2.3,<1.3 . As you can see, this is most useful for projects that follow a semantic version number. A common usage is to mark the minimum version you rely on, like ~1.2 (allow 1.2 or more of any version, but not including 2.0). Since there should be no backward compatibility problem in theory until 2.0, it works well. You'll also see another usage of it, using the ~ specified minimum version, but allowing the last digit of the version number to rise.

Note: Although 2.0-beta.1 strictly earlier than 2.0 , however, ~1.2 this version is not installed according to the version constraints, for example. As mentioned above ~1.2 only means that the .2 part can be changed, but 1. the part is fixed.

Stability

Only stable distributions are considered by default. If you also want to get RC, beta, alpha or dev versions, you can use the stabilize flag. You can set the minimum stability for all packages instead of each dependent one.

Install dependent packages

Get the defined dependencies to your local project, just call the composer.phar run install command.

php composer.phar install

Next to the previous example, this will find monolog/monolog the latest version and download it to the vendor directory. It is a convention to put a third-party code into a specified directory vendor . If it is Monolog, the directory will be created vendor/monolog/monolog .

Tip: If you are using Git to manage your projects, you may want to add vendor them to your .gitignore files. You don't want to add all of your code to your repository.

The other thing is that the install command creates a composer.lock file into the root directory of your project.

composer.lock-Lock file

After the installation dependency, Composer will write the exact version number list to the file at the time of installation composer.lock . This locks the specific version of the project.

Please submit your application composer.lock (including composer.json ) to your repository

This is important because the install command checks to see if the lock file exists, and if it does, it downloads the specified version (ignoring composer.json the definition in the file).

This means that anyone who builds a project will download the exact same dependency as the specified version. Your continuous Integration server, production environment, other developers on your team, everything, everyone uses the same dependencies to mitigate the impact of potential errors on your deployment. Even if you are developing your project on your own, you can rest assured that you will be able to continue working even if you have already released many new versions of your dependencies since then within six months.

If the file does not exist composer.lock , Composer will read composer.json and create the lock file.

This means that if your dependencies are updated with the new version, you will not get any updates. To update your dependent version, use the update command. This will get the latest matching version (depending on your composer.json file) and update the new version into the lock file.

php composer.phar update

If you only want to install or update a dependency, you can whitelist them:

php composer.phar update monolog/monolog [...]

Note: for libraries, it is not always recommended to submit a lock file, please refer to: Vault lock file.

Packagist

Packagist is the main repository of Composer. A Composer library is basically the source of a package: It records where the package can be obtained. Packagist's goal is to become a central storage platform for everyone using library resources. This means that you can have require any package there.

When you visit Packagist website (packagist.org), you can browse and search for resource bundles.

Any open source project that supports Composer should publish its own package on packagist. Although not necessarily published on Packagist to use Composer, it makes our programming life easier.

Auto Load

For the library's auto-load information, Composer generates a vendor/autoload.php file. You can simply introduce this file and you will get a free auto-load support.

require ‘vendor/autoload.php‘;

This makes it easy for you to use third-party code. For example: If your project relies on Monolog, you can start using this class library like this, and they will be loaded automatically.

$log=NewMonolog\logger(' Name ');$log->Pushhandler (new monolog\handler\streamhandler  ( ' App.log '  monolog\ logger::warning) ;  $log ->addwarning ' Foo '           

You can composer.json autoload add your own autoloader in the fields.

{    "autoload": {        "psr-4": {"Acme\\": "src/"}    }}

Composer will register a PSR-4 autoloader to the Acme namespace.

You can define a mapping from a namespace to a directory. At this point src , the root directory of your project, and the vendor folder sibling. For example, the src/Foo.php file should contain Acme\Foo classes.

autoloadAfter you add a field, you should run the install command again to generate the vendor/autoload.php file.

Referencing this file will also return an instance of Autoloader, where you can store the return value of the containing call in a variable and add more namespaces. This is useful for automatically loading class files in a test suite, for example.

$loader = require ‘vendor/autoload.php‘;$loader->add(‘Acme\\Test\\‘, __DIR__);

In addition to PSR-4 automatic loading, CLASSMAP is also supported. This allows classes to be loaded automatically, even if they do not conform to the PSR-0 specification. For details, see Automatic loading-reference.

Note: Composer offers its own autoloader. If you don't want to use it, you can just introduce the vendor/composer/autoload_*.php file, it returns an associative array, and you can configure your own autoloader with this associative array.

Composer.json: Project installation