Detailed introduction to Composer

Composer is a very popular PHP package dependency management tool. It has replaced the PEAR package manager. It is necessary for PHP developers to master Composer.

For users, Composer is very simple. Download the required code package to the vendor directory with a simple command, and then developers can introduce the package and use it.

The key lies in the composer.json defined by your project, which can define the project dependencies There may be multiple packages (there may be multiple), and the dependent packages may depend on other packages (this is the benefit of components). You don’t have to worry about these. Composer will automatically download everything you need. Everything lies in the definition of composer.json.

Composer is very transparent to users, but the concept behind it still needs to be understood. Its birth is not accidental. Thanks to the rapid development of Github, the PHP language is becoming more and more modern. , appears to be higher.

In order to understand Composer, let’s first have a general understanding of its structure:

The structure of Composer

Composer command line tool:
This understanding is It’s relatively simple. Download the code you need through the user-defined Composer.json. If you just simply use Composer, then it’s enough to master some specific commands

Autoloading code loader:
Through Composer, developers can use it in a variety of ways, and the key lies in the namespace concept of PHP and the development of the PSR-4 standard. Composer only developed a code based on these two Autoloader

Github:
With Github, PHP developers can host open source code on it, and the development of Composer originates from Github, the essence of Composer The above is to download the code on Github to the local.

Packagist:
For users, the command line tool of Composer is used, so what about the command line tool? Knowing how many packages can be used by users mainly relies on Packagist. Packagist is Composer's main package information repository. Package developers host specific codes on Github and submit package information to Packagist, so that users It can be used through Composer.
Composer queries Packagist based on the locally defined composer.json information. Packagist parses based on Composer.json/Package.json information and finally corresponds to the github warehouse. Composer also relies on it when downloading the code. Regarding Composer.json on the Github repository, there are three types of composer.json involved, and their meanings are different.

##Composer.json:

This is The core of Composer is the rules of Composer. The three types of Composer.json are also mentioned above. You must pay attention to the distinction when using them. I always messed up when I first learned.

Composer command line tool

composer init

Users can create composer.json under their own projects to define the dependency packages of your project, or they can create composer.json interactively through composer init.

composer install

should be the most commonly used command. Composer will put the downloaded package into the vendor directory under the project based on the local composer.json installation package, and also put the package version information during installation. Put it into composer.lock to lock the version.

In fact, during installation, if it is found that the composer.lock version is consistent with the code version in the current vendor directory, Composer will do nothing. The purpose of .lock is to allow you to work with peace of mind under the current version without getting the latest version of the package.

composer update

So how to update composer.lock to get the latest version of the package What? You can update the latest version of the package through this command

composer config

It is recommended to understand this command. The global configuration is saved in COMPOSER_HOME/config.json, and the non-global configuration information is Stored in the directory of this project.

composer config --list -gcomposer config -g notify-on-install falsecomposer global config bin-dir --absolute

composer create-project

This command is not commonly used, but I personally think it is still very important. Using the ordinary install command is to download all the dependency packages of the project to the vendor directory of the project. With this command, all the code and Placing the dependent packages in a directory is equivalent to executing a git clone command. Generally, package developers may use this command to fix bugs.

composer global

This is a global installation command, which allows you to execute Composer commands in the COMPOSER_HOME directory, such as install and update. Of course, your COMPOSER_HOME must be in the $PATH environment.

For example, execute composer global require fabpot/php-cs-fixer, now the php-cs-fixer command line can be run globally. If you want to update it later, you only need to run composer global update

composer dump-autoload

When you modify the composer.json file under the project, you do not have to run the composer update command to update. Sometimes you can use this command to update the loader. For example, if you want to reference a local custom package (not from packagist) , this command will be explained through practice later.

composer require

If you create the composer.json file manually or interactively, you can directly use this command to install the package

composer require cerdic/css-tidy:1.5.2composer require "ywdblog/phpcomposer:dev-master"

–prefer-source and –prefer-dist parameters

–prefer-dist: For stable packages, Composer installation generally uses this parameter by default, which can also speed up the installation. For example, it is possible to install the corresponding package directly from packagist without actually downloading the package from Github.

–prefer -source: If you use this parameter, it will be installed directly from Github. After installing the package, the vendor directory will also contain .git information

composer require "ywdblog/phpcomposer:dev-master" --prefer-source
#Contains .git information in the vendor/ywdblog/phpcomposer directory

How to add an agent to Composer

It is very slow to download using Composer in China, you can Accelerate through two methods

composer config repo.packagist composer "https://packagist.phpcomposer.com"

Edit composer.json

"repositories": { "packagist": { "type": "composer", "url": "https://packagist.phpcomposer.com"
}
}

Autoloading code loader

Composer itself integrates an autoloader, supporting PSR-4, PSR-0, classmap, files autoloading.

Here is an example to illustrate how to reference classmap, files through Composer, and the local conforms to PSR-4 Standard code

Edit composer.json

"autoload": { "classmap": ["othsrc/","classsrc.php"], "files": ["othsrc/filesrc .php"], "psr-4": {"Foo\Bar\": "src"}
}

composer dump-autoload
Through the above operations, for PSR -4 is equivalent to registering a PSR-4 autoloader (from the FooBar namespace)

If you don’t want to use Composer’s autoloader, you can directly include the vendor/composer/autoload_*.php file and configure your own loader.
Specific examples are hosted on github, please refer to.

Repositories

About Repositories, it is not necessary to understand them, but if you master them, you can better understand Composer. For Repositories, its Chinese The documentation and English documentation explain it very well, and some excerpts are also made here.

Basic concepts

Package:

Composer is a dependency management tool that installs some locally Resource packages and descriptions of packages (such as package names and corresponding versions). The more important metadata descriptions are dist and source. Dist points to an archive, which is a package of data of a certain version of a resource package. source Point to a source under development, which is usually a source code repository (such as git)

Repository:

A repository is the source of a package. It is a list of packages/versions .

Composer will look at all the repositories you define to find the resource packages required by the project (this sentence is very important).

Packagist.org has been registered with Composer by default (or understand Packagist.org is the default warehouse type of the Composer resource library)

Composer resource library type

The Composer resource library includes four types, the default is the composer type, which is used by packagist.org Resource type.

It uses a single packages.json file, which contains all resource package metadata. When you publish the package to pckagist.org, the default system will create a packages.json, But I didn’t find the file corresponding to my package.

VCS Resource Library Type

If you want to build a private Composer private resource library type, you can use this type. Here is an example, For example, if you define composer.json in your project as follows, you can use the corresponding code on Github.

{ "repositories": [ { "type": "vcs", "
"url": "https://github.com/ywdblog/phpcomposer" } ], "require": { "ywdblog/phpcomposer": "dev-master" } }

When running composer update, Comoser actually downloads the package from Github instead of from pckagist.org.

In addition, if you need to use the Package resource library type or PEAR resource library Type, please refer to the official documentation. Generally, define the name and version attributes in composer.json.

Composer.json

Composer.json has been mentioned many times in this article. For example, if you want to use a third-party package, you need to define composer.json locally. After Composer installs the third-party package, composer.json will also be found in the third-party package directory. , then both are called composer.json, what is the difference? It is very important to understand this.

If you define a composer.json under your own project, this package is called a ROOT package. This composer.json defines the conditions required by your project (for example, your project may depend on a third-party package).

Some properties in composer.json can only be used by the ROOT package, such as the config property only in the ROOT package. Take effect.

Whether a resource package is a ROOT package depends on its context. For example, if you git clone ywdblog/phpcomposer, then the local phpcomposer directory is the ROOT package. If you are in the local phpcomposer directory, composer require ywdblog /phpcomposer, then your project phpcomposer is the ROOT package at this time.

To learn about composer-schema.json, you can refer to this website. As a mature framework, Laravel defines composer.json very classic

About the package version

When users configure composer.json locally, they can specify the specific version of the package required. Composer supports downloading packages under tags or branches from the Github repository.

For Tags on Github, Packagist will create a version of the corresponding package, which conforms to X.Y.Z, vX.Y.Z, X.Y.Z-package types. That is to say, although there is only one specific version of the package on Github, Composer supports multiple forms. Reference method, for example:

composer require monolog/monolog 1.0.0-RC1
composer require monolog/monolog v1.0.0-RC1
composer require monolog/monolog 1.0.*
composer require monolog/monolog ~1.10

For branches on Github, Packagist will create a version of the corresponding package. If the branch name looks like a version, a package version of {branch name}-dev will be created. number, if the branch name does not look like a version number, it will create a version number in the form dev-{branch name}

composer require monolog/monolog master-dev
composer require monolog/monolog master .x-dev

Summary:

To understand Composer, the most important thing is practice. Finally, you can understand PSR-4 and namespaces, and you can also try to publish your project to pckagist.org.

The above is the detailed content of Detailed introduction to Composer. For more information, please follow other related articles on the PHP Chinese website!