We’ve been using extensions published by others. Have you thought about releasing one of your own?

Today we’ll talk about how to publish a Composer extension and what to look for.

From the composer. Json

Yes, since we use a composer extension to install dependencies based on a composer. Json file, we should also have a listing describing ourselves – composer.

You may ask, I am currently developing a system that uses Composer to install dependencies, and I have a composer in my own project root directory. Is my project an extension package?

Yes, your project is also a package, but at the moment it cannot be published and installed by someone else in Composer because it is missing one of the most important elements —- name.

It is the name of the composer. Json that we talked about earlier. I think you have understood the specific name convention through the previous study

If you don’t know what to use as a vendor name, it’s usually a good idea to use your Github username. Although package names are case insensitive, the convention is to use lowercase letters and hyphens as word separators.

For example, the following are all good

  • abei2017/emoji
  • abei2017/yii2-emoji
  • china-go/emoji
  • china-go/yii2-emoji

In order to provide more for users and composer, you should make sure that your package has enough precise descriptions and limitations

  • Composer quick table
  • A menu – Unscramble the contents of Composer. Json

Of course, Composer also provides init commands to help us create composer. Json in a question-and-answer manner.

Code structure and automatic loading

Starting with structure, a package should have test documentation, source code, documentation, and even some examples, so putting a bunch of files in a folder is not a good structure. I usually like this, but it’s not limited.

My structure is as follows

-src/
--src/Emoji.php
--src/Event.php
--src/....
-test/
--test/a.php
--test/b.php
--test/...
-example/
--example/example01.php
--example/example02.php
--example/...
-README.md
-composer.jsonCopy the code

For autoloading, I like and recommend using the PSR-4 specification if it’s a new extension. This requires the following definition in composer. Json

"autoload": {
    "psr-4": {
        "abei2017\\emoji\\": "src"}}Copy the code

For details about the PSR-4 specification, see the official website. After installing your extension, the mapping will appear in the vendor\ Composer \ Autoload_psr4.php file.

Here I put abei2017/yii2-emoji composer. Json description to help you understand.

{
    "name": "abei2017/yii2-emoji"."description": "An Emoji extension for Yii2"."type": "yii2-extension"."keywords": ["yii2"."extension"]."license": "MIT"."authors": [{"name": "abei"."email": "[email protected]"}]."require": {
        "yiisoft/yii2": "*"."emojione/emojione": "^ 3.1"
    },
    "autoload": {
        "psr-4": {
            "abei2017\\emoji\\": "src"}}}Copy the code

A brief explanation is as follows

  • The name is abei2017/yii2-emoji, abei2017 is my Github name
  • Release using the MIT protocol
  • Yii2 – Emoji can run depending on the proper deployment of Yiisoft/Yii2 and Emojione/Emojione, see require
  • Automatic loading uses PSR-4, namespace and extension under SRC file – by – file mapping

Commit to making

Then create an empty repository on Github and remember the repository git address. Go back to the extension directory on our machine and do the git operation.

>git init
>git remote set-url origin --push --add [email protected]:abei2017/xxx.git
> git add .
> git commit
> git push origin masterCopy the code

Of course, this is much easier if you use PHPStorm. portal

Anyway, you now have your local git file in a remote repository.

coding… coding… coding

After countless nights, you complete the extended functionality.

Then we built a version of it on Github called 1.0

Submitted to Packagist

As you all know, Packagist (packagist.org/) is composer’s…

Registered account

First we had to sign up for an account on Packagist, which was pretty easy.

submit

Then click on the top right corner of the submit (packagist.org/packages/su…). Submit. Packagist automatically recognizes Git/SVN. You only need to submit the github repository address.

After a while, Packagist has done its own analysis and collection, and you can use composer require XXX. Domestic mirroring users need to collect packages on the Packagist at intervals.

Upgrade your package

After a while, you have a new version of the package, maybe a new version 2.0 on Github. Go back to your Packagist page and click “Update”. You can also automatically update the package via Github Service Hook

alt

At this point, you have successfully released your package, easy.