Setup of a PHP project with composer.json

Explanations about the content of the JSON file of a project to use Composer as a dependency manager.

In it we have already explained the entire workflow that will allow you to adopt Composer in your day-to-day PHP development. Really with what you know and a quick reference in the documentation for details that we may have missed, you have everything it takes to use Composer.

However, we have gone very “on tiptoe” through the structure of the composer.json file that helps us to declare the characteristics of our project and the dependencies it may have.

But Beware, the composer.json is useful not only for Composer to know the dependencies to install for your project, it is also useful in the case that you want to release your project as a package for other people to use and publish it in Packagist. In this article we are going to focus more on what you need to define your dependencies.

The composer.json schema

The schema (scheme) of a JSON defines the structure of the document as well as the possible values ​​that each of its fields have. The specific address where you can find the complete description of the composer.json schema can be found at this documentation URL:

Fields that describe your project

Let’s now see a series of fields to offer information about us as developers of a project. These are the data that you would need to send to Packagist, but are not needed internally for Composer to work, but rather to tag your development, mention authors, etc.

yam:

It is used to indicate the name of the author, it is made up of two parts, the “vendor” (the company or nick of the developer or group that created it) and the name of the project itself. Of course, a vendor can create several libraries or packages and they would all be linked to the same vendor with different project names.

description:

It is the description that we offer of this package. It is normally a single line text.

home page:

A URL of the project website.

authors:

It is an array with the authors of the project. Each of the elements of this array is in turn a JSON object where different data can be indicated: name, email, homepage, role (role within the project).

“authors”:

Define dependencies

At the development level of our own applications, the most important field where we must focus is the definition of the dependencies, as well as the versions that we want to be installed, or updated for each of those dependencies.

requires:

It is an object with a series of key/value pairs that define each of the dependencies that Composer must install for our project. In the key we must indicate the name of the package that it depends on (which you get from the Packagist site) and as a value we indicate the version that we want to be installed, or the range of versions.

“require”: { “respect/validation”: “0.6.*”, “phpunit/phpunit”: “>=4.0”, “tinymce/tinymce”: “dev-master” }

In the key/value pairs of each of the dependencies, the part of the name of the vendor and the library is very easy to obtain. You simply go to Packagist, search and choose the package that best suits you and copy the name string. For example “respect/validation” indicates that “respect” is the vendor and “validation” is the name of the library.

You can also use Packagist for the version part, because there you will find the list of versions released from that library and available as packages. What you’ll see is that the expression that defines the version has some “wildcards” that you need to learn to deal with. In general you can use these expression variants.

• Exact Version: Tell Composer to install an exact version, and only that one. It means that the package will never be updated, because your project must have that version and not another. For example “4.3.1”.
• Range of versions: allows you to indicate versions that are greater than a certain one, smaller or that are between one version and another. For example “>=2.0”.
• Wildcard: Allows you to say any version of a major release. Well, you can use something like “4.*” to indicate to always keep version 4 and whatever. Or something more restrictive like “4.2.*” which will always put you at version 4.2.x. Logically, in this case when you update, the most advanced version allowed by that wildcard will be placed.
• Virgulilla (the tail of the eñe): allows to indicate the version in a different way, “next significant version”. For example, “~2.2” will always return version greater than or equal to 2.2 and less than 3.0. For example “~2.2.1” will set the version greater than 2.2.1 and less than 2.3.
• It also allows things like “dev-master” which will be the current development version, which may not be stable. “1.0.*@beta” which will allow you to place beta versions or “@dev” which also refers to development versions that may suffer from instability.

To find other possibilities, please consult the Composer documentation, at these links:

Thats it for now. With the information you have, we are sure that you will be able to get the most out of Composer to manage the dependencies of your PHP projects.