Composer for the smallest

Good day.

When I first dealt with the composer, I sketched a small cheat sheet for myself and now, after a while, I present it to the public in a slightly modified form.
This publication is relevant to those who first encountered the indispensable package manager for PHP.

So, Composer is a package manager for PHP.

What is Composer and the simplest example of its use for?

Take for example this project.
If in a nutshell: this is a set of scripts for working in the VK API.
Accordingly, several libraries
are needed for these scripts. Libraries are listed in the composer.json file - the key file when working with composer.

Example composer.json:


In this project 5 libraries are used. Accordingly, if the developer decides to publish this project on github, then it is enough for him to throw the folder with scripts into the turnips and composer.json, which will describe the libraries necessary for the work of this project. The simplicity is obvious: the turnips do not need to follow all the necessary libraries following the trailer files. Takes up less space, easier to distribute the project.

Work example:

Download project


The scripts folder directly contains the project scripts, for which these 5 packages are required.

Starting the installation of packages:


After installation, the vendor folder appears, where the installed packages are folded and the autoload.php file is formed. We connect


this file to the project and everything - the libraries are connected, you can safely work with them.


The simplicity is obvious: you do not need to download and connect libraries and their dependencies yourself, the composer will do everything for you. And this whole bundle is connected with a single autoload.php file.
All packages that are in the vendor are added to the autoloader. In this case, composer relies on the files composer.json, which should be in each package. Creating a composer.json package is the task of the package developer, all that is required of the package consumer is to describe in the project composer.json which packages need to be included.

This is an example of the composer.json project:


This is an example of the composer.json package:


The require section contains the dependency of this package - the guzzle http library, which is required for the getjump / vk library to work. In this case, i.e. from the point of view of the consumer of packages, all sorts of package dependencies are not our “concern”, composer will deal with dependencies itself.

The namespace of the package is written in the section autoload


getjump \\ Vk \\ - the name of the namespace
src / getjump / Vk / - directory in which files with package classes are located
Working with this library in a project:


Core and Friends are library classes that are expanded and written in the src folder in accordance with the PSR-4 standard. Again, the formation of the package structure is the work of the package creator.
For us, as a consumer of the package, it is enough to
include in our project include '../vendor/autoload.php';
and all these classes and namespaces will work just fine.
In this case, we do not need to bother and write autoloader. Composer will do this itself when executing the install command.


Composer installation globally

1) First you need to have the path to the directory with the PHP interpreter be registered in the environment variable path.
Check if this is the case:
php –version


If the output is of this type, then you can skip this step.
For example, Windows 7
System -> Advanced System Settings -> Advanced -> Environment Variables

Next we will be interested in the path variable:


Enter the path to the interpreter


* С long time on my computer is the xampp assembly, the assembly itself is not needed here, but the interpreter from it is quite suitable (version PHP - 5.6).

2) Restart the terminal.
Create a directory and set composer (I put on disk D)
cd /
mkdir bin
cd bin
php -r "readfile ('');" | php
echo php "% ~ dp0composer.phar"% *> composer.bat


3) Add the path to composer.bat to the path environment variable, for example for D: \ bin should be: You


can add to path
D: \ Users \% userName % \ AppData \ Roaming \ Composer \ vendor \ bin \
for more convenient use of the tools globally installed through Composer.
(I have the Users folder located on disk D, and a C has created a symlink for it).
That's it, the composer is installed and fully operational.

Also: during installation, you can catch the error
The APPDATA or COMPOSER_HOME environment variable
The solution was found here
Add the APPDATA variable with the value D: \ Users \ GSU \ AppData \ Roaming


Install Composer locally

There is an option to put the composer locally, but in most cases there is no obvious need for this.
However, the installation is even easier.
Since the program is not globally installed, you need a boot file (mini-program composer), to download it we write the command:
php -r "readfile ('');" | php is
now in the project directory appeared file composer.phar
Everything, you can use.
php composer.phar require [package name]

Differences between global and local installation

Commands are run differently with local and global installations:

For example:
Local: php composer.phar require silex / silex ~ 1.1
Globally: composer require silex / silex ~ 1.1

For a local installation, you need to download the installation file to the current project folder
php -r " readfile (''); »| php

This file is not needed for a global installation. Composer runs under any current directory.


install - install packages registered in composer.json
update - update packages for
dumpautoload - rebuild the autoloader
require somepackage / somepackage: someversion - add a new package (by default packages are installed from the repository office). When installing, the package is
written to composer.json update --lock - update the lock file composer.lock
config --global cache-files-maxsize "2048MiB" - an example of changing the configuration parameter
--profile - adding this parameter to any command will turn on the runtime and amount of used memory
--verbose - detailed information about the
show operation being performed - installed - list of installed packages with a description of each
show - platform - information about PHP
--dry-run - rehearsal command execution. May be added to the install and update commands. Emulates the execution of a command without its direct execution. Required to check if the installation of packages and dependencies will succeed.
remove - remove the package. The exact opposite of require

Syntax composer.json

Package naming and package description options A package

name consists of two parts separated by a slash: vendor name (vendor name) and library name.


If the package is designed in accordance with the PSR-4 standard, but is published not on, but on github, then instead of the version of the package, you need to register the branch and repository for this package:


Example of connecting the library that lies on github, but without it according to the PSR-4 standard, and is an ordinary jumble of files with classes and functions.

Approximate view:


Pqr / superlib is the same “wrong” library.

In the repositories section for it, we write such a construction. The


key point is the autoload section, here we specify the files we need with classes and functions.
Library structure:


File contents:


Accordingly, the getCurrentTime () call in the project will look something like this:
$ timer = new pqr \ superlib \ TimerClass;
echo $ timer-> getCurrentTime ();


When specifying acceptable package versions, you can use exact matching (1.2.3), ranges with comparison operators (<1.2.3), combinations of these operators (> 1.2.3 <1.3), “last available” (1.2. *), Tilde symbol (~ 1.2.3) and the caret (^ 1.2.3).
The tilde specification (~ 1.2.3) will include all versions up to 1.3 (not inclusive), since in semantic versioning this is the moment of introducing new functionality. In this case, the last of the stable minor versions will be obtained. Those. only the last digit will change - 1.2.5, 1.2.8 and so on.

Indicating the insertion mark (^ 1.2.3) literally means “be wary of only critical changes” and will include versions up to 2.0. With regard to semantic versioning, changing the major version is the moment of making critical changes to the project, so versions 1.3, 1.4 and 1.9 are suitable, while 2.0 is no longer.
Those. only the first digit does not change.

Tilde: ~ 1.2.3 is the most common and secure way to specify a version.

Composer.lock file

The composer.lock file saves the current list of installed dependencies and their versions. Thus, at the moment when the dependency versions are already updated (update command), other people who will clone your project will receive the same versions. This allows you to make sure that everyone who receives your project has a batch environment identical to the one you used during development, and helps to avoid errors that could arise from updating versions.

Each time the update command is executed, the updated versions of the packages are written to composer.lock. This file is pushed under the version control system and when installing packages on a new server, those versions of packages that are written in this file will be delivered. When executing the install command, the composer will primarily rely on composer.lock. Thus, on different servers the same batch environment will be guaranteed in terms of versions.

Also, the composer.lock file contains a hash of the composer.json file.
And if the json file has been edited, the composer will warn you that the lock file does not match the json file.

In this case, you need to run the command composer update --lock, which will update composer.lock.


Differences install from update in the context of using composer.lock

The composer install command does the following:

Checks if composer.lock exists:

- if not, resolves dependencies and creates it
- if composer.lock exists, installs the versions specified in it Composer update

command : - Checks composer.json - Determines the latest versions based on specified in this file - Installs the latest versions - Updates composer.lock in accordance with the installed

Example use from the point of view of the creator of the project

There is a project without installed packages.


We installed several libraries.


We have composer.json with information about packages.


We can supplement it and distribute the project with this file.


Another user downloaded our project, executed install, and all necessary packages were deployed in the project.


Example of use from the point of view of the package creator

For example, I created a class with a method that will display the URL of the current page.


The class is designed as a package and uploaded to github.


Compiled by composer.json


Register at the office. repositories and add the package, specifying the link to the repository, in which it lies


Everything, the package is added I


check the package's performance The package has been


delivered, here is our class:


Call the method


Everything is ok.


Composer and PhpStorm



Configuring the ability to edit Composer packages


If the option is set, it will not be so easy to take and edit the files inside the vendor / * / *

Install packages


Nuances, subtleties, difficult situations

Error: Warning: The Complement in Composer.json. You may be getting outdated by dependencies. Run update to update them. Nothing to install or update
Solution: composer update --lock

It takes a long time to update with a large number of installed libraries.
Composer checks all package dependencies, and if there are many packages, then this is a long time.
Solution: if you need to update only one library, then we specify it explicitly:

composer update package / name

You can also add the "--prefer-dist" parameter (although, in theory, it should be enabled by default), then the composer will try to install the library from a zip archive, not a clone repository.

The "****. Json" file could not be downloaded: failed request!
Composer is trying to pull a packet over HTTP, although it needs HTTPS
Solution: composer config - global repo.packagist packoist

The package does not have a stable version, and installing the dev version is not allowed in the config.
Solution: either set the “minimum-stability” parameter: “dev” and “prefer-stable”: true to install stable versions as much as possible, or - if this is your own package - create a tag with the version (the sticker in the readme on the github should show version)

Development history and key changes

- the first release took place on March 1, 2012 and the whole 2012 tool is actively developing
- January 2014 - implemented a startup based on PSR-4
- March 2016 - a beta version (1.0.0-beta1) was released. The show --tree commands have been added to display the installed packages as a tree, why-not — shows why the package cannot be fixed, update --interactive - allows you to select which packages to update, as well as many other improvements and fixes.
- April 4, 2016 - the first stable release of Composer was introduced - 1.0.0

December 2014 - one of the key commits to the composer repository
The essence of the change - the garbage collector is disabled



Official package repository: Composer
A great big tutorial on using Composer: command
list and a detailed example of the composer.json file: composer.json.

Also popular now: