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).

An example homepage of a Composer Package on packagist.org

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.

1. Creating your project structure
2. Coding
3. 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