— y2sunlight 2020-07-16

Packagist に戻る

ここでは Packagist にパッケージを登録する前に知っておきたい基礎知識を説明します。本章は、Packagist サイトの https://packagist.org/about の「How to submit packages?」を翻訳し補足したものです。

関連記事

• Packagist アカウントの作成
• Packagist パッケージ登録の基礎知識
• Packagist パッケージの登録方法

リンク

• https://packagist.org/ — Packagistの本家
• https://packagist.org/about — Packagistについて（設定方法の情報が掲載されている）

First of all, you must pick a package name. This is a very important step since it can not change and it should be unique enough to avoid conflicts in the future.

The package name consists of a vendor name and a project name joined by a /. The vendor name exists to prevent naming conflicts. For example, by including a vendor name both igorw and seldaek can have a library named json by naming their packages igorw/json and seldaek/json.

In some cases the vendor name and the package name may be identical. An example of this would be `monolog/monolog`. For projects with a unique name this is recommended. It also allows adding more related projects under the same vendor later on. If you are maintaining a library, this would make it really easy to split it up into smaller decoupled parts.

Here is a list of typical package names for reference:

// Monolog is a library, so the vendor name and package name are the same.
monolog/monolog

// That could be the name of a drupal module (maintained/provided by monolog,
// if the drupal team did it, the vendor would be drupal).
monolog/monolog-drupal-module

// Acme is a company or person here, they can name their package with a common name (Email).
// As long as it's in their own vendor namespace it does not conflict with anyone else.
acme/email

Vendor names on packagist are protected once a package with that name has been published. That means you can not publish packages with a vendor name that already exists on packagist without permission. To be able to publish packages for an already existing vendor name you need to be maintainer of at least one package within that vendor.

The composer.json file should reside at the top of your package's git/svn/.. repository, and is the way you describe your package to both packagist and composer.

A typical composer.json file looks like this:

{
    "name": "monolog/monolog",
    "type": "library",
    "description": "Logging for PHP 5.3",
    "keywords": ["log","logging"],
    "homepage": "https://github.com/Seldaek/monolog",
    "license": "MIT",
    "authors": [
        {
            "name": "Jordi Boggiano",
            "email": "j.boggiano@seld.be",
            "homepage": "http://seld.be",
            "role": "Developer"
        }
    ],
    "require": {
        "php": ">=5.3.0"
    },
    "autoload": {
        "psr-0": {
            "Monolog": "src"
        }
    }
}

Most of this information is obvious, keywords are tags, require are list of dependencies that your package has. This can of course be packages, not only a php version. You can use ext-foo to require php extensions (e.g. ext-curl). Note that most extensions don't expose version information, so unless you know for sure it does, it's safer to use “ext-curl”: “*” to allow any version of it. Finally the type field is in this case indicating that this is a library. If you do plugins for frameworks etc, and if they integrate composer, they may have a custom package type for their plugins that you can use to install the package with their own installer. In the absence of custom type, you can omit it or use “library”.

Once you have this file committed in your repository root, you can submit the package to Packagist by entering the public repository URL.