Composer configurations and its community
Introduction
Technology is governed by physical laws, which consists of protocols and configurations. In the previous tutorial, we discussed extensively on the concepts of the composer repository and how they work, in this tutorial we will take a deep look at an important section of the composer.json file, called the “config” section.
Config is synonymous to configuration; the name “config” gives us an overall idea of what this section does. This section can be regarded as the power house of composer as we can reconfigure all the default behavior of composer here.
{
“config”:{
“config-name”: ”config-value”,
}
}
The above code snippet shows the config section for a composer.json file. We will now take a deeper look at its contents.
#process-timeout: This by default is 300seconds. It is the time interval process like git clone can run before composer assumes that the links are dead. This can be extended, if your connection is poor, or if the package you are downloading is large.
#use-include-path: This also by default is false, but when enabled, that is set to “true”, it compels the composer to look for the classes in the path and include them.
#preferred-install: It defaults to “auto” and can be of source, dist or auto. This option basically allows you to set the install method Composer will prefer to use. It can optionally be a hash of patterns for more granular install preferences.
#store-auths: This option determines what action composer should take after authentication. It could be set to “true”, “false” or “prompt”.
#github-protocols: This is a list of protocols to use when cloning a package from github.com. The defaults protocols used are “https”, “ssh”,”git”. The git protocol is present if secure-http is disabled. You can set any of these protocols to be the default protocol used by composer to either pull or push to github.
#github-oauth : This is a list of domains and the corresponding “oauthtoken” to be used in accessing these domains. This is essential when accessing private repos on github. When accessing private repos on gitlab, we use gitlab-oauth and gitlab-token instead.
#disable-tls: By default, this is false. When set to true, all HTTPS URLs will be accessed as HTTP and all the network level encryption will be disabled. Enabling this is highly discouraged, as it possesses a lot of security risks. An alternative to enabling this is to enable the php_openssl extension in php.ini.
#secure-http: Defaults to true and it ensures that only HTTPS URLs can be downloaded via composer. In a situation where access to http is seriously needed, this can be disabled.
#cafile: This points to the location where the Certificate Authority File can be found on the system. PHP 5.6 and above detects this automatically.
#capath: In a scenario where cafile is not specified, or the certificate not found, the directory assigned to the capath is searched for a suitable certificate. The capath must be a properly hashed certificate directory.
#platform: This allows you fake platform packages (PHP and extensions) so that one can emulate a production env or define a target platform in the config.
#vendor-dir: The default directory for saving packages is the vendor directory. We can install dependencies into a different directory if you want to. Just by setting the vendor-dir parameters.
#bin-dir: This is defaulted to vendor/bin, all projects with binaries are symlinked into this directory.
#data-dir: This directory stores old and past composer.phar files to be able to rollback to older versions. The default directory for windows is “C:\Users\<user>\AppData\Roaming\Composer” and “$XDG_DATA_HOME/composer” for Unix systems that follow the XDG Base Directory Specifications, and “$home” on other Unix systems.
#cache-dir: On windows his defaults to “C:\Users\<user>\AppData\Local\Composer” and “ $XDG_CACHE_HOME/composer” on Unix systems that follow the XDG Base Directory Specifications, and “$home/cache” on other Unix systems. Stores all the caches used by Composer.
#notify-on-install: This allows composer to send notification to a URL whenever a package is installed. This by default is true.
#discard-changes: This has three options. “true”, false” and “stash”. It allows us to set the default style for handling dirty updates in non-interactive mode. ”true” ,will always discard changes in vendors, while “stash” will try to stash and reapply, and “false” will just apply the changes.
#archive-format: This specifies the archiving format to be used by composer. By default, it uses “tar” for archiving files.
#htaccess-protect: This is used to limit composer on the directories at which htaccess files will be created. It could be set to either true or false. When seted to false composer will not create “htaccess” files in the composer home, cache, and data directories.
The Composer Community:
Composer is an open source project where everyone is free to contribute to the development of composer. The only strict rule to follow when contributing to composer is that all your code must follow the PSR-2 coding standard.
In this tutorial, we have discussed extensively on composer configurations and its community. I hope you this will encourage you to help contribute to the development of composer.
Don’t forget to share this tutorial with your friends, like and comment in the comment section. See you in the very next tutorial.
Previous:
Composer command line interface and commands (Part 6)
Next:
A gentle introduction to composer as a dependency manager
It will be nice if you may share this link in any developer community or anywhere else, from where other developers may find this content. Thanks.
https://www.w3resource.com/php/composer/composer-configurations-and-its-community.php
- Weekly Trends and Language Statistics
- Weekly Trends and Language Statistics