The concept of composer packages and repositories

Introduction

The word repositories and packages won’t be any new  to us by now, if we have been following from the previous tutorials. We have created, used and published repositories in the past using composer and also made our repositories to be auto-updating, but understanding the concept of repositories and how they work is different from just creating and using them.

Therefore, in this tutorial, we will look at repositories in detail and try to understand their  concepts, types and their working principles.

#Basic Concepts

1. Package: Composer as we know is a dependency manager, it installs packages

locally. A package could mean any directory with some contents, but in our case, it contains some PHP codes, and it comes to some description which has a name and a version used to identify a particular package.

Composer internally sees every version of a package as a single package, this is to ensure code stability. This may not actually be of worth when using composer, but it’s worth knowing

Aside name and versions, a package contains some useful metadata. One of the most relevant, used for package installation is the source definition, which describes where to get the package contents. The package data maps to the contents of the package and this has two options.

• #Dist : This is a packaged version of the package data, usually in a released stable form.
• #Source : This is mainly used for development. It usually originates from a source code repository such as git. We make use of this whenever there is a need to modify the downloaded package.

#Repositories: A repository is a package source. It is a list of packages/versions. The repository houses your package so the composer searches and finds our packages in the repositories.

By Default, only the Packagist repository is registered in the composer but more repositories can be added to a package by declaring them in composer.json file. Repositories are only available to the root package and the repositories defined in our dependencies are not loaded, thus composer does not load repositories reclusively.

#Types of Repositories

There are many types of composer repositories available for use, but we will look at the three most used repositories and try to explain them a bit.

1. Composer Repositories: The main repository type is the composer repository. It uses a single package.json file where all the package metadata are defined. By default, composer assumes that any repository created is a composer repository unless stated otherwise in the composer.json file by adding the “repository “ fields. Composer repositories are published on Packagist.org.
2. Version Control System Repositories: The includes repositories hosted and accessed directly through the various versioning system like git, svn, fossil or hg. For such repositories, we add an extra field in the composer.json file when defining them, to enable the composer to know where to search for such systems. This extra repository field is shown in the code snippet below

   {
   “repositories” : [
   	{
   	“type” : “vcs”,
   	“url” : “https://github.com/agavitalis/hello-composer”
   }
   ],
   “require” :{
   		“monolog/monolog”: “master”
   }
   }
   

   The above code snippet describes how the repository field of a VCS type of composer is defined.
3. Pear:  Another type of repository is the Pear repository, where such  repositories are installed by the composer using PEAR channels. Composer when downloading pear packages will prefix then with the “pear” prefix to avoid conflicts. In the composer.json file, some pear specific fields will also be added to tell composer that these packages are pear packages.

   {
       "repositories": [
           {
               "type": "pear",
               "url": "https://pear2.php.net"
           }
       ],
       "require": {
           "pear-pear2.php.net/PEAR2_Text_Markdown": "*",
           "pear-pear2/PEAR2_HTTP_Request": "*"
       }
   }
   

   The above code snippet also illustrates the definition of the repository key in the composer.json file of a Pear repository.

#Composer Working Principles

The Composer as a package manager is powerful and very useful. In the management of packages, composer by default searches for the packages defined in the require block of the composer.json file, and other specified repositories if any.

When downloading this, it ensures that packages are not downloaded recursively in the sense that, it only downloads on the dependencies specified on the package.json file at the root directory of our application.

These downloaded dependencies are locked in the composer-lock.json file, to ensure that the right packages are downloaded when our projects is been used by another.

If the Autoload option is specified, the composer will create a vendor folder, where it houses all the downloaded packages for autoloading.

In summary, we have explored the concepts of composer packages, types and their working principles.

Don’t forget to share, like and comment on this tutorial. Feel free to follow us on social media. See you in the next tutorial.

Previous: Package installation using composer
Next: The composer.json schema