Packagist パッケージ登録の基礎知識

— y2sunlight 2020-07-16

ここでは 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 にすでに存在するベンダー名のパッケージを許可なしに公開することはできません。既存のベンダー名のパッケージを公開できるようにするには、そのベンダー内の少なくとも一つのパッケージの保守担当者である必要があります。

パッケージのバージョン管理

パッケージの新しいバージョンは、バージョン管理システムのリポジトリに作成したタグから自動的にフェッチされます。

バージョニングを管理する最も簡単な方法は、composer.json ファイルからバージョンフィールド( version )を省略することです。その後は、バージョン番号はタグとブランチ名から解析されます。

タグ/バージョン名は X.Y.Z または vX.Y.Z と一致する必要があり、RC, beta, alpha または patch バージョンのオプションのサフィックスが付いています。次に、有効なタグ名の例をいくつか示します:

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

ブランチは自動的に “dev” バージョンとして表示され、ライブラリの最新かつ最高のものを試してみたい人なら誰でも簡単にインストールできますが、リリースにタグを付けてはいけないという意味ではありません。セマンティックバージョニングの使用を強くお勧めします。

例えば、dev-master は masterブランチの最新バージョンを表します。

composer.jsonの作成

composer.json ファイルは、パッケージの git/svn/などのリポジトリの先頭に配置する必要があり、packagist と composer の両方にパッケージについて説明する手段となります。

典型的な composer.json ファイルは次のようになります。

{
    "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"
        }
    }
}

この情報のほとんどは明白で、キーワード( keywords )はタグであり、パッケージが持つ依存関係のリスト( require )が必要です。もちろん、これはphpバージョンだけでなく、パッケージでもかまいません。ext-foo を使用して、php拡張モジュールを要求できます（例：ext-curl）。ほとんどの拡張モジュールはバージョン情報を公開しない点に注意して下さい。従って、確実に公開していない限り、“ext-curl”:“*” を使用して、どのバージョンでも許可する方が安全です。最後に、タイプフィールド( type )ですが、上記の場合は、これがライブラリであることを示しています。フレームワークなどに対するプラグインを作成し、それらが composer を統合している場合、独自のインストーラーを使用してパッケージをインストールするために使用できるプラグイン用のカスタムパッケージタイプがある場合があります。カスタムタイプがない場合は、それを省略するか、“ライブラリ” を使用できます。

このファイルをリポジトリのルートでコミットしたら、パブリックリポジトリのURLを入力してパッケージを Packagist に送信できます。

更新スケジュール

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

JSを有効にしている場合、新しいパッケージは、送信後、即座にクロールされます。

自動更新（GitHub / BitBucketフック）のない既存のパッケージは、更新のために週に1回クロールされます。フックを有効にすると、プッシュするたびに、パッケージがクロールされ、また、クロールが失敗した場合は少なくとも月に1回はクロールされます。保守担当者としてログインしている場合は、パッケージ画面で手動更新をトリガーすることもできます。

すべてのパッケージに GitHubまたはBitBucketのサービスフックを設定することを強くお勧めします。これにより、負荷が軽減され、パッケージがほぼ瞬時に更新されます。以下のハウツーを確認してください。

https://packagist.org/about　内の “How to update packages?” の項を参照して下さい。

GitHubの場合は、本編の「Packagist アカウントの作成」内の「githubパッケージの更新方法」に “How to update packages?” の翻訳が記載されています。

検索インデックスは5分ごとに更新されます。検索インデクサーが最後に実行されてからクロールされたパッケージがインデックス（または再インデックス）されます。（※即ち、クロールされて（自動更新の場合はプッシュとほぼ同時刻）から最大で5分以内の再インデックスされるという事）

目次

Packagist パッケージ登録の基礎知識

パッケージのネーミング

パッケージのバージョン管理

composer.jsonの作成

更新スケジュール