PHP composer で自作ライブラリ管理

ソースコードを沢山書いていくと、ちょっとした便利ライブラリ的なコードを再利用したくなり、その整理をどうするか？という問題が出てきます。

その昔は、開発者は自分のハードディスクに保存しておき、利用の度にファイルコピーといった再利用方法をとっていたと思います。

そのうち、Subversion や Git などのバージョン管理システムが出てきて、組織や個人のリポジトリで管理するようになり、現在では Github や GitLab などのクラウドサービスを利用できるようになりました。

また、プログラミング言語側でもパッケージマネージャーの概念が浸透し、Java ならば Maven、Python では pip など、言語には標準的にパッケージマネージャーが存在するようになっています。

PHP のパッケージマネージャーとしては Composer があり、今ではすっかりメジャーになりました。

以前は、１つのプロジェクトでメインのリポジトリ以外にライブラリ用を使いたい場合、git submodule などの仕組みを使って複数のライブラリを組み込んでいました。ところが PHP Composer が登場して、自作パッケージを公開ライブラリの packagist に登録して再利用してみると、断然 packagist の方が便利に感じます。

なぜ Composer の方が圧倒的に便利なのか？その理由が判らなかったのですが、やっと判明しました。それは、autoload 機能です。
Composer の autoload 機能のお陰で、いちいち require … と書かなくても、ライブラリに含まれるクラスや関数をロードできる点が、圧倒的に便利です。

自作ライブラリやオートロードを上手く使いこなすには、名前空間の設計も必要になってきます。

ライブラリを個人リポジトリで管理するには、いつも通りの git commit & push で良いのですが、Composer パッケージとするには、いくつかの制限事項がありますが、それらは公式サイトなどを参照してください。

リポジトリ登録 (push) の際に必要なことは、タグでバージョンを付けることが必要です。

コンポーザーが Git リポジトリにアクセスするためのトークンを設定します。

composer config --global github-oauth.github.com xxxxxxxxx  # GitHub の場合
composer config --global gitlab-token.gitlab.com xxxxxxxxx  # GitLab の場合

あるいは、composer.json と同じディレクトリに auth.json を作成します。
https://getcomposer.org/doc/articles/authentication-for-private-packages.md#http-basic

{
    "http-basic": {
        "example.org": {
            "username": "username",
            "password": "password"
        }
    }
}

ライブラリのある Git リポジトリの URL を登録します。

composer config repositories.my/pkg vsc https://github.com/my/pkg.git

最後のコマンドはマニュアルで composer.json を編集することでも実装できます。

{
  "repositories": {
    "my/pkg": {
      "type": "vcs",
      "url": "https://github.com/my/pkg.git"
    }
  }
}

エンジニアが自分の生産性を最大化するには、その時々において最適なツールを正しく理解して使うことが求められまる。正しく理解する、ということが表面上の使い方理解に留まらず、自分のビジネスや生産性にどういった影響を与えるかまでを理解することが必要になります。

エンジニア人生の終盤にそんなことに気づき、悲しくなります。