How To Make a PHP Package

It’s never been easier for me and for anyone in the community to build and share PHP Packages.

This is all thanks to the great tools and developers: Composer, Packagist, Github, The PHP League, Aura for PHP, PHP-FIG, The Checklist, Laravel, Symfony, NextPack and many other great stuff.

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:

1. Create the Skeleton (5 min)
2. Setup Git (5 min)
3. Setup Composer (5 min)
4. Setup PHPUnit (5 min)
5. Setup Continuous Integration Service (5 min)
6. 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):

1. Reading Config file (15 min)
2. 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:

1. 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:

1. Write the Documentation “README” (N/A)
2. Setup Github Repository (2 min)
3. Publish on Packagist (3 min)

Now I will share some standards I consider while developing new package, that you should consider too:

1. Use Semantic versioning. And try not to introduce backwards compatibility breaks.
2. Write unit tests. Aim for at least 60% coverage in the first version.
3. Try not introduce dependencies on other packages.
4. Conform to PSR-1 and PSR-2 as the coding style guide. (to apply the conventions on an existing package install PHP Code Sniffer.)
5. Conform to PSR-4 for autoloading.
6. DocBlock your code.
7. Have an extensive README. And keep it updated.
8. Default to the use of the Solar vocabulary for method names.
9. Keep ‘Public’ functions names short (maximum of two words).
10. Compose functionality through dependency injection, rather than through inheritance and base classes.
11. Try to limit the levels of indentation per function (one per function is great).
12. Use Continuous Integration tools, to automatically check coding standards and run tests.
13. Prefer explicit configuration over implicit convention.
14. Exclude non-essential files in .gitattributes.
15. It’s always better to have a ‘Changelog’.
16. 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