— 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について（設定方法の情報が掲載されている）

( packagist でパッケージを提出するには ) まず第一に、パッケージ名を選択する必要があります。これは変更できないので非常に重要なステップであり、将来的に競合を回避するために十分に一意である必要があります。

パッケージ名は、スラッシュ( / ) で結合された ベンダー名 と プロジェクト名 で構成されます。ベンダー名は、名前の競合を防ぐために存在します。たとえば、ベンダー名を含めることにより、igorw と seldaek の両方に、パッケージに igorw/json と seldaek/json という名前を付けて、json という名前のライブラリーを作成できます。

場合によっては、ベンダー名とパッケージ名が同じになることがあります。この例は、monolog/monolog です。一意の名前を持つプロジェクトの場合、これが推奨されます。また、後で同じベンダーに関連プロジェクトを追加することもできます。ライブラリを保守している場合、これにより、ライブラリを小さく切り離したパーツに分割することが本当に簡単になります。

参考の為に、典型的なパッケージ名のリストを次に示します：

// Monolog はライブラリで、ベンダー名とパッケージ名が同じです。
monolog/monolog

// これはdrupalモジュールの名前のようです（monolog によって保守/提供されてます。
// drupalチームがそれを行っているとしたら、ベンダーはdrupalになります）。
monolog/monolog-drupal-module

// Acme は会社または人です。ここではパッケージに一般的な名前（Email）で名前を付けることができます。
// 独自のベンダー名前空間にある限り、他の誰とも競合しません。
acme/email

packagist のベンダー名は、ひとたび、その名前でパッケージが公開されると保護されます。つまり、packagist にすでに存在するベンダー名のパッケージを許可なしに公開することはできません。既存のベンダー名のパッケージを公開できるようにするには、そのベンダー内の少なくとも一つのパッケージの保守担当者である必要があります。

New versions of your package are automatically fetched from tags you create in your VCS repository.

The easiest way to manage versioning is to just omit the version field from the composer.json file. The version numbers will then be parsed from the tag and branch names.

Tag/version names should match 'X.Y.Z', or 'vX.Y.Z', with an optional suffix for RC, beta, alpha or patch versions. Here are a few examples of valid tag names:

1.0.0
v1.0.0
1.10.5-RC1
v4.4.4beta2
v2.0.0-alpha
v2.0.4-p1

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.

New packages will be crawled immediately after submission if you have JS enabled.

Existing packages without auto-updating (GitHub/BitBucket hook) will be crawled once a week for updates. When a hook is enabled packages are crawled whenever you push, or at least once a month in case the crawl failed. You can also trigger a manual update on your package page if you are logged-in as a maintainer.

It is highly recommended to set up the GitHub/BitBucket service hook for all your packages. This reduces the load on our side, and ensures your package is updated almost instantly. Check the how-to below.

The search index is updated every five minutes. It will index (or reindex) any package that has been crawled since the last time the search indexer ran.