Creating and Publishing a Composer package
In this Story, we’ll go around the creation of a Composer package and its publication to the Composer Registry (Packagist).
If you want to make your code available to the world, in the form of a PHP library, you may want to create a Composer package and publish it, so people can use it.
In this example, we’ll act as if we’re working on a from-scratch (blank) project.
Creating a composer package is pretty easy, as there are only 3 steps.
- Creating your project structure
- Coding
- Publishing your work
Let’s go!
Project Structure — The composer.json file
The composer.json file is the root of your package. It contains metadata about the library/project you want to publish.
To create a basic one, you can run the composer init
command, and answer the prompts, or follow this template:
{
"name": "your-vendor-name/package-name",
"description": "A description of what your package does",
"require": {
"php": ">=7.4",
"symfony/console": "^5.4|^6.0"
},
"require-dev": {
"phpunit/phpunit": "^10.4",
"phpstan/phpstan": "^1.10"
},
"autoload": {
"psr-4": {
"YourMainNamespace\\": "src/"
}
},
"authors": [
{
"name": "Your full name",
"email": "Your contact email address",
"homepage": "Your homepage (if you have no website you can use your GitHub profile URL)"
}
]
}
Most fields are pretty straightforward, but if you’re new, some can be tricky, let’s break this file down!
name
contains your package name, the one you’ll need to composer require
when you want to require this dependency in another project.
description
contains a description of your project, it should fit within 100 characters.
The require
field contains all the dependencies needed for the library to work properly.
The require-dev
object contains the development dependencies, needed to work on the project (like testing frameworks, linters, analysis tools…).
The autoload
entry contains the Composer autoloading information for your project. Using the PSR-4 key, you can tell Composer what namespace your classes should be mapped to.
Usually, your main namespace (usually the project’s name) should be mapped to the src
directory.
The authors
field holds your personal information and the ones of anyone who has had a significant place in its development, it is optional but highly recommended.
If you want to learn more about the composer.json
file, I recommend you visit the official structure page.
Coding
Well, that’s your job now!
Implement your logic, and when you’re done, go to the next step.
Publishing your package
You’ve got your code working fine, now it’s time to publish it on GitHub. Create a repository, push your code, and create a new tag for your project.
git tag 1.0.0
git push origin 1.0.0
To publish your package, simply visit https://packagist.org/packages/submit and paste your GitHub URL, it is that simple!
Packagist will automatically parse your GitHub Tags to handle the versioning of your package.
Whenever you make a change to your package, create a new tag respecting Semantic Versioning, push it to GitHub, and that’s it!
Now, if you want to require your package in a PHP project, simply use the following command:
composer require vendor-name/package-name
Publishing a private package
If you want to publish a private package (for example for your company or school…), you can use Private Packagist.
I hope this tutorial will help you with Composer! The process is quite simple, but it can get tricky if you’ve never done it before.
If you liked this content, check out my other publications, you might learn something!
As always, have a good day 🎉
PS: Here is my first package, RetryableCommands. It adds a retry mechanism to Symfony commands