Back in the days, you had to install php applications from a zip or tar.gz. Just download this tar.gz from Drupal’s download page, extract it to your project folder, and you are good to go. Unlike in other advanced interpreted languages, where package and dependency management was present from the beginning. Python’s pip and Ruby’s bundler comes to my mind and the shocking realisation of why such a poor programming language was able to gain more popularity when there were better tools available. Time passed, and the PHP community had to come out with something similar too. PEAR was there for some time but was not even close to what was available for other languages. Finally, Composer was born.
Composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and it can manage (install/update) them for you.
Composer by default is pulling packages from Packagist, but for internal use, it’s a good idea to set up a local composer repository.
Issues Composer is trying to solve
Composer’s main feature is dependency management. It deals with pulling the code of libraries into the vendor folder. Without composer, we had to carry all the libraries that our project depends on and pollute the VCS history with it.
With Composer, the size of the project reduced significantly, and the dependencies are not committed to git.
Reduce debugging time
Libraries can also depend on other libraries. Composer is handling the incompatibility issues and denies the installation request if one dependency is requesting a library that’s not compatible with one other dependency.
One of the best thing about Composer is it’s trying to regularise the hard work of autoloading. Autoloading is no longer the task of the framework, the use of SPL autoloader is the job for Composer.
It supports PSR-0, PSR-4, class mapping as well as files autoloading. We need to require only one file, and it’s done. Play nicely with namespaces and PSR-4 compatible class names and let Composer handle the autoloading for your project including all the libraries.
Maintaining a library package
Package maintainers had to maintain tar.gz files for each version of the package or release new versions through GitHub every time there was an important update. Thanks to Composer with git tags and branches, this process is now fully automatic. It’s recommended to use Semantic Versioning, so packages tend to follow the same logical and easy to understand versioning.
Install Magento with Composer
If you want to build a new Magento site, you need to start with Composer. Though some people would prefer the traditional way, it’s highly discouraged.
Composer installs all the libraries required for Magento and also runs some install scripts to generate boilerplate files in the
To install Magento using Composer, execute the following command:
composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition <installation directory name>
Because Magento is using its composer repository, which requires authentication, it asks for authentication tokens at some point. Your public key is your username; your private key is your password which can be acquired from Magento Marketplace My Profile - Access Keys
When done, 2 essential files will appear in your project directory: composer.json and composer.lock. The .json file is the smaller, contains the minimum version numbers for each package for Magento. The .lock file is locking packages to version numbers ensuring when somebody is executing
composer install locally, they get the same version.
On the other hand,
composer update looks at the composer.json file directly, installs the new versions of the dependencies, if available.