It’s never been easier for me and for anyone in the community to build and share PHP Packages.
In this article, I will show you how I build my PHP packages really quick.
I’ll start by listing my steps for developing a modern PHP package:
1. BASIC SETUP:
These steps are required by almost every modern PHP package:
- Create the Skeleton (5 min)
- Setup Git (5 min)
- Setup Composer (5 min)
- Setup PHPUnit (5 min)
- Setup Continuous Integration Service (5 min)
- Create Basic Files “License, Contributing” (5 min)
To save this 30 minutes of creating all these repetetive files, I used to clone The League Skeleton and then get started.
The League Skeleton is a PHP package skeleton, contains the most required files by almost every package.
2. COMMON FUNCTIONALITY:
These steps are optional (speaking of myself, I almost always need them for my packages):
- Reading Config file (15 min)
- Automatic Driver Initialization (15 min)
To save this 30 minutes of rewriting these functionalities over and over, I prefer to clone the NextPack and get all these features ready for me, to get started.
NextPack is a rich PHP package skeleton, contains more file templates then The League Skeleton. And unlike the League Skeleton, The NextPack contains functionalities (provided by the NextPack Library).
What’s included in NextPack?
- Rich package skeleton, (containing common files required by almost every PHP package)
- Clean folder structure
- Code samples, (demonstrating HOW and WHERE the code should be implemented)
- Test samples, (with PHPUnit)
- Basic configurations, (for the most popular required tools)
- Version Control: Git (.gitattributes, .gitignore)
- Continuous Integration: Travis and Scrutinizer (.scrutinizer.yml, .travis.yml)
- Testing: PHPUnit (phpunit.xml)
- Package Manager: Composer (composer.json)
- Common functionalities, (provided by the Nextpack Library nextpack/library).
- Reading config files, and serving them in the package classes
- Initializing drivers automatically “when the package supports multiple drivers”
For more details about this great starter kit, read this README file.
3. PACKAGE SPECIFIC CODING:
There is only one step in this phase:
- Coding the package specific functionalities (N/A)
4. PUBLISHING AS OPEN SOURCE:
These steps cannot be automated as far as I know but they are the easiest anyway:
- Write the Documentation “README” (N/A)
- Setup Github Repository (2 min)
- Publish on Packagist (3 min)
Now I will share some standards I consider while developing new package, that you should consider too:
- Use Semantic versioning. And try not to introduce backwards compatibility breaks.
- Write unit tests. Aim for at least 60% coverage in the first version.
- Try not introduce dependencies on other packages.
- Conform to PSR-1 and PSR-2 as the coding style guide. (to apply the conventions on an existing package install PHP Code Sniffer.)
- Conform to PSR-4 for autoloading.
- DocBlock your code.
- Have an extensive README. And keep it updated.
- Default to the use of the Solar vocabulary for method names.
- Keep ‘Public’ functions names short (maximum of two words).
- Compose functionality through dependency injection, rather than through inheritance and base classes.
- Try to limit the levels of indentation per function (one per function is great).
- Use Continuous Integration tools, to automatically check coding standards and run tests.
- Prefer explicit configuration over implicit convention.
- Exclude non-essential files in .gitattributes.
- It’s always better to have a ‘Changelog’.
- Do never ever have duplicated code.
If you have never built a PHP Package before, it is the right time to build one. And you will enjoy it : )
Follow me on Twitter @Mahmoud_Zalt