About Composer Packages
Composer packages makes maintaining your code easier. For example, you have a small library which is used in a few projects at the same time. You want to add a new feature or fix a bug.
You can go through all projects which are using the library and update them. But what if new update needs to add new dependencies? You should add them manually too. It will take too much time and chance to break something is very high.
Another way is to package the library in a Composer package and make it accessible somewhere across the Internet (you actually don’t need make it public). In this case you update the code, add required dependencies in config and release a new version. After that, you just go through projects and run a single command in their root directory:
composer update
This is much easier than the previous scenario.
Package structure
In general Composer package is usual PHP code organized in a special way. It’s rather flexible and you are free to change it if you want. My usual package structure is shown below:
project_root/ project_root/tests project_root/src project_root/composer.json
Pretty simple, isn’t it?
In the tests directory I place phpunit tests. In the src directory I place source files. File composer.json contains information about the package.
Name
You must specify the name of your package. The name consists of two parts: project name and package name itself, e.g. “zendframework/zend-dom”. If your package is not a part of larger project you can use the package name (“phpmailer/phpmailer”) or your name (“jonnyw/php-phantomjs”) instead project name.
Description
Optional field. Just short description of the package.
Author
Optional field. Here you can specify your name and contacts, e.g.
"authors": [
{
"name": "Vlad",
"email": "me@fullstackvlad.com"
}
],
Dependencies
If your code has any dependencies, you must specify them here. Be very careful – if you miss some required package or php extension it will cause installing and updating problems. For example:
"require": {
"zendframework/zend-dom": "*",
"katzgrau/klogger": "*",
"adodb/adodb-php": "^5.20",
"ext-curl": "*",
"ext-date": "*",
"ext-mysql": "*",
"ext-mysqli": "*",
"phpunit/phpunit": "4.8.6",
"phpmailer/phpmailer": "~5.2",
"jonnyw/php-phantomjs": "4.*"
},
Autoload
The main part of the package. Here you define the code structure. I recommend you to follow PSR standard in organizing your code. Example of autoload section for PSR-4 package:
"autoload": {
"psr-4": {
"MyPackageRootNameSpace\\": "src/",
"MyPackageRootNameSpace\\Tests\\": "tests/"
}
}
You can get more information about PSR and namespaces here. Btw, you can avoid using tests directory, but it is a good practice to write unit tests for your code and add them to the package.
Repositories
The biggest Composer repository is packagist.org. There you can find tons of packages ready to use. All popular packages are stored there. But some times you need to use another repository (for example, if you placed your package in private Git repository). In this case you can specify additional repo in your config:
"repositories": [
{
"type": "vcs",
"url": "https://vlad@bitbucket.org/<user_name>/<repo_name>.git"
}
],
In this example, I’ve added a private Bitbucket repository where my library is stored. Now when I release a new version of the library, all I need to do – go through all projects which use the library and run command:
composer update
Conclusion
Composer + PSR + Git is an amazing stack for PHP developers. Since found, I you use it all the time and my productivity grew up dramatically. In further blogs I’ll tell how to add more useful technologies to this stack.