Composer on ララジャパン

composerをもっと知ろう（４）ローカルのパッケージをLaravelで使う

Fri, 21 Feb 2025 10:58:09 +0900

皆さんは、DGFTのベリトランスの支払決済のPHPのSDKキットを使用したことありますか？それを利用するには彼らのウェブサイトからファイルをダウンロードして、プロジェクトに置いてそれをパッケージとしてインストールします。今回はその仕組みの説明です。ローカルにパッケージを作成してそれをcomposer requireします。

自分のパッケージを作成

まず、デモとしてあるヘルパー関数の定義を含むパッケージを作成します。このパッケージには１つのヘルパー関数しかなく、インストールしたら以下のように、全角の英数字文字列を半角に変換する関数、to_hankaku()を使うことができます。

Psy Shell v0.12.7 (PHP 8.2.15 — cli) by Justin Hileman
> to_hankaku('１２３');
= "123"

便利そうでしょう。

まず、Laravelのプロジェクトを新規作成して、プロジェクトのディレクトリ直下にpackagesのディレクトリを作成して、以下のような構造で必要なファイルを作成します。

├── app
...

packages
└── larajapan
    └── japanese-utils
        ├── composer.json
        └── src
            └── helpers.php
...

上では、composer.jsonとhelpers.phpのみがファイルで他は皆ディレクトリです。larajapanが開発者のアイデンティティでその下のjapanese-utilsが今回のパッケージ名となります。

まずそのパッケージのcomposer.jsonの中身を見てみましょう（混乱していけないのは、このcomposer.jsonはjapanese-utilsのパッケージのcomposer.jsonであり、これからそれをインストールしようというLaravelのプロジェクト、つまりルートパッケージのcomposer.jsonではありません）。

packages/larajapan/japanese-utils/composer.json

{
    "name": "larajapan/japanese-utils",
    "description": "helpers to manipuliate a japanese string",
    "version": "1.0.0",
    "require": {
        "php": ">=7.4",
        "ext-mbstring": "*"
    },
    "autoload": {
        "files": [
            "src/helpers.php"
        ]
    }
}

ここでは、パッケージ名（name）、説明（description）、バージョン（version）、必須条件（require）、ロードの指示（autoload）が含まれます。to_hanakaku()の関数では、mbstringのPHPのモジュールのmb_convert()を使用し、さらにタイプヒントも使用するので、それを対応しているPHPバージョン7.4以上であることをインストールの前提とします.

今度は、その関数を定義するhelpers.phpを見てみましょう。

packages/larajapan/japanese-utils/src/helpers.php

if (!function_exists('to_hankaku')) {
    function to_hankaku(string $zenkaku): string
    {
        return mb_convert_kana($zenkaku, 'as'); // 全角英数字と空白を半角に変換
    }
}

とても簡単な定義ですが、他のパッケージですでに定義されていたら困るので、!function_exists(’to_hankaku’)の条件を入れています。

Laravelのプロジェクトにインストール

同じプロジェクトのディレクトリ内にパッケージを作成したものの、これだけではプロジェクトで先ほどのto_hanakaku()は使えません。プロジェクトにインストールすることが必要です。

今度は作成したパッケージのではなくプロジェクト（ルートパッケージ）のcomposer.jsonの編集が必要です。以下のrepositoriesのブロックが追加した部分です。

composer.json

{
    "$schema": "https://getcomposer.org/schema.json",
    "name": "laravel/laravel",
    "type": "project",
    "description": "The skeleton application for the Laravel framework.",
    "keywords": ["laravel", "framework"],
    "license": "MIT",
    "repositories": [
        {
            "type": "path",
            "url": "./packages/larajapan/japanese-utils",
            "options": {
                "symlink": true
            }
        }
    ],
    "require": {
        "php": "^8.2",
        "laravel/framework": "^11.31",
        "laravel/tinker": "^2.9"
    },
...
}

“type”: “path”がローカルのパッケージがレポジトリということを指示し、その場所 “url”にパッケージの相対の場所を指定します。そして、“options”として、“symlink”: trueは、プロジェクトにおいて使用されるパッケージを収めるvendorのディレクトリにおいて、作成したパッケージへのsymlinkを張るという指示です。ちなみにfalseならファイルのコピーとなります。

これでインストールの準備は完了です。通常のパッケージのインストールのようにcomposre requireを実行しましょう。

$ composer require larajapan/japanese-utils

インストール後には、composer.jsonは更新され、“larajapan/japanese-utils”: “^1.0”,のエントリーが追加されているのがわかります。

composer.json

{
...
    "require": {
        "php": "^8.2",
        "larajapan/japanese-utils": "^1.0",
        "laravel/framework": "^11.31",
        "laravel/tinker": "^2.9"
    },
...
}

vendorのディレクトリを見ると、以下のようにパッケージへのsymlinkとなっています。

$ ls -l vendor/larajapan
total 0
lrwxrwxrwx 1 kenji kenji 40 Feb 19 16:42 japanese-utils -> ../../packages/larajapan/japanese-utils/

これで、このLaravelのプロジェクト内で、to_hankaku()のヘルパーをどこでも使えるようになります。

最後に

自分が作成したパッケージは、Packagistに登録したものでもなく、githubのレポジトリに置いたプライベートのパッケージでもありません。そのようなパッケージが必要となるのは不思議と思われるかもしれません。しかし、以下のようにいくつか必要となるケースがあります。

将来はPackagistにおいて自分で開発したパッケージを共有したいが、完成度が低いので暫くは自分のプロジェクトだけ使う
今まで使用していたgithubにあるパッケージはもうメンテインされていなくダウンロードして自分のプロジェクトだけで使えるようにする
プロジェクトが肥大化したのでパッケージとしてモジュール化して使う
あえて自社のサービスのSDKキットをPackagistでパブリックで共有することをせずに、サービスを利用する開発者にローカルにダウンロードしてからcomposerでインストールしてもらう。日本で有名なDGFTのベリトランスの決済のPHPのSDKキットはまさにそれです。

composerをもっと知ろう（３）バージョンに関して

Mon, 06 Jan 2025 05:58:08 +0900

今回は、composer.jsonでrequireやrequire-devにリストされるパッケージのバージョンに関して説明します。今まで気にもとめていなかった ^11.9などの意味を解明します。

composer.json

まず、前回の「composerをもっと知ろう（２）composer create-projectでは何が起こっている？」で記載したcomposer.jsonを再度見てみましょう。

{
    "name": "laravel/laravel",
    "type": "project",
    "description": "The skeleton application for the Laravel framework.",
    "keywords": ["laravel", "framework"],
    "license": "MIT",
    "require": {
        "php": "^8.2",
        "laravel/framework": "^11.9",
        "laravel/tinker": "^2.9"
    },
    "require-dev": {
        "fakerphp/faker": "^1.23",
        "laravel/pail": "^1.1",
        "laravel/pint": "^1.13",
        "laravel/sail": "^1.26",
        "mockery/mockery": "^1.6",
        "nunomaduro/collision": "^8.1",
        "phpunit/phpunit": "^11.0.1"
    },
...
}

“laravel/framework”: “^11.9”のような記述があります。laravel/frameworkはパッケージ名で、^11.9はインストールするバージョンを指示していると思われますが、その記事を書いた時点では実際にインストールされたバージョンは11.34.2でした。どうして11.9ではないのでしょう。11.9の前についているキャレット＾はいったい何でしょう。

^11.9の意味

“laravel/framework”: “^11.9”の意味を解明するには、laravel/frameworkのパッケージをローカル環境にインストールして、gitのタグを見る必要があります。

パッケージをインストールした後に、以下のコマンドを実行して、v11のみのタグを抽出します。

$ git tag --sort=v:refname | grep v11

コマンドの出力は、以下のようになります。長いので途中…で割愛と示しています。これを書いている時点では最新はv11.37.0です。

v11.0.0
v11.0.1
v11.0.2
v11.0.3
v11.0.4
v11.0.5
v11.0.6
v11.0.7
v11.0.8
v11.1.0
v11.1.1
v11.2.0
v11.3.0
v11.3.1
v11.4.0
v11.5.0
v11.6.0
v11.7.0
v11.8.0
v11.9.0
v11.9.1
v11.9.2
...
v11.36.1
v11.37.0

上において、タグの最初の数字がメージャーのバージョン番号で、それ以下はマイナーのバージョン番号です。例えば、v11.37.0では、11がメジャーで37.0がマイナー。

Laravelの新規のプロジェクトを作成するときは、composer installが実行されます（この時点では、composer.lockのファイルはまだ存在しないと仮定）。プロジェクトにとってcomposer.jsonで指定されるパッケージはその時点で最新のパッケージのインストールを試みます。しかし必ずしもパッケージの最新とも限りません。例えば、Laravel 10.xをインストールするのに最新の11.xがインストールされては困ります。それゆえに、^11.9のような指定が使われます。

composer.jsonの“laravel/framework”: “^11.9”でのキャレット＾は、11.9以上で12.0.0未満のバージョンでその時点で最新のバージョンをインストールしなさい、という指示です。それゆえに、前回の記事を書いた時点では最新のv11.34.2が、この記事を書いている現時点ではv11.37.0がインストールされます。

この理解にとてもいいツールがありますので紹介します。

https://semver.madewithlove.com/?package=laravel%2Fframework&constraint=%5E11.9

上のリンクをクリックすると以下のような画面となります。

先ほどのlaravel/frameworkのパッケージで^11.9を指定したときにインストールされるバージョンのリストが赤箱でハイライト表示されます。そこで、^11.0とか^11.37とか入力してみてどれがハイライトされるか試してみてください。他のパッケージも指定してみてください。

さて、ここで不思議に思うはどうしてインストールすべきバージョンが最新の１つ（ここでは、v11.37.0）だけでなくいくつもハイライトされているのかです。v11.9.0からv11.37.0までのすべてのバージョンがハイライトされていますね。

これは共にインストールする他のパッケージとの依存があるかもしれないからです。もしかして、他のパッケージでは、laravel/frameworkへの依存があり、そのパッケージのcomposer.jsonにおいて、 “laravel/framework”: “11.18.1”と１つのバージョン（バージョンの前にキャレットがない）のみを指定しているかもしれません。その場合はプロジェクトでインストールされるlaravel/frameworkのバージョンは11.18.1のみと制限されます。プロジェクトがインストールしたいバージョンと依存するパッケージがインストールしたいバージョンをともに満たすためにです。

composer.jsonで記載されるバージョンの形式には、他にも~11.9とか11.9.*とか^6.0|^7.0|^8.0|^9.0|^10.0|^11.0とかあります。以下で詳しい説明があります。 https://getcomposer.org/doc/articles/versions.md

composer.lock

composer installを最初に実行した後には、composer.lockのファイルが作成されます。これは、その名の通り、実行時にインストールされたすべてのパッケージのバージョンの情報が含まれています。次回に、違う環境（例えばライブ環境とか）でこのファイルがあれば、まったく同じバージョンでパッケージをインストールしてくれるので、異なる環境での同じバージョンのパッケージがインストールされることを保証してくれます。

composerをもっと知ろう（２）composer create-projectでは何が起こっている？

Sun, 08 Dec 2024 08:59:55 +0900

誰しも、composer create-project laravel/laravelのコマンドで新規のLaravelのプロジェクトの開発を開始します。Laravelが凄いのは、この実行後にすぐにプロジェクトを立ち上げて(php artisan serve）ブラウザでサイトを閲覧することが可能となることです。その実行では画面に英語でいろいろと経過が表示されますが、いったい何が起こっているのでしょうか？

Laravelの新規のプロジェクトの作成

最新のLaravel 11.xを使用してプロジェクトを作成するには、以下のようなコマンドの実行が必要です。

$ composer create-project laravel/laravel laravel-11x

上のコマンドラインにおいて、

create-projectは、composerの新規プロジェクト作成のオプション名です。
laravel/laravellは、プロジェクトのルートとなるパッケージ名です。指定したパッケージ名をpackagist.orgのサイトでで探します。 https://packagist.org/?query=laravel/laravel マッチするパッケージが存在するgithubのレポからパッケージのダウンロードとなります。
laravel-11xは新規プロジェクト名で、その名前でプロジェクトのディレクトリを作成して、そこに必要なパッケージをダウンロードしてインストールし設定を行います。

ルートパッケージのバージョンの指定も以下のように可能です。

$ composer create-project laravel/laravel laravel-10x "10.*"

上では、 10.*は、Laravel 10で一番最新のバージョンで新規プロジェクトが作成されます。

プロジェクト作成の設計図

今回の新規のプロジェクトの作成として指定されるlaravel/laravelは、以下からダウンロードされます。 https://github.com/laravel/laravel そこに含まれる、composer.jsonのファイルに、プロジェクトに必要なパッケージのダウンロードとインストール、そしてプロジェクト立ち上げに必要な.envやDBの作成などが指定されています。

ファイルの中身を見てみましょう。phpのプロジェクトですがフォーマットはjsonとなっています。途中今回の話に関係ないところは…で省いています。

{
    "name": "laravel/laravel",
    "type": "project",
    "description": "The skeleton application for the Laravel framework.",
    "keywords": ["laravel", "framework"],
    "license": "MIT",
    "require": {
        "php": "^8.2",
        "laravel/framework": "^11.9",
        "laravel/tinker": "^2.9"
    },
    "require-dev": {
        "fakerphp/faker": "^1.23",
        "laravel/pail": "^1.1",
        "laravel/pint": "^1.13",
        "laravel/sail": "^1.26",
        "mockery/mockery": "^1.6",
        "nunomaduro/collision": "^8.1",
        "phpunit/phpunit": "^11.0.1"
    },
...
    "scripts": {
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ],
        "post-update-cmd": [
            "@php artisan vendor:publish --tag=laravel-assets --ansi --force"
        ],
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate --ansi",
            "@php -r \"file_exists('database/database.sqlite') || touch('database/database.sqlite');\"",
            "@php artisan migrate --graceful --ansi"
        ],
        "dev": [
            "Composer\\Config::disableProcessTimeout",
            "npx concurrently -c \"#93c5fd,#c4b5fd,#fb7185,#fdba74\" \"php artisan serve\" \"php artisan queue:listen --tries=1\" \"php artisan pail --timeout=0\" \"npm run dev\" --names=server,queue,logs,vite"
        ]
    },
...
}

上において、“require”は、laravelのルートパッケージがライブの環境で必要なパッケージです。“require-dev”は、開発環境で必要なパッケージです。たったこれだけですが、前回に説明したようにそれらが依存するパッケージがあるので実際にインストールパッケージは100以上の数になります。 “scripts”の部分は、特定なイベントごとに実行する指令が記述されています。

create-project実行の作業

composer create-projectを実行すると、以下のような経過表示となります。すべて掲載するととても長いのでパッケージのLockingやDownloadingやInstallingの多くは割愛しています。

上から順番に説明していきます。

プロジェクトディレクトリの作成

Creating a "laravel/laravel" project at "./laravel-11x"

まず、コマンド実行で指定した新規プロジェクト名のディレクトリlaravel-11xを作成します。

ルートパッケージのインストール

Creating a "laravel/laravel" project at "./laravel-11x"
Installing laravel/laravel (v11.3.3)
  - Downloading laravel/laravel (v11.3.3)
  - Installing laravel/laravel (v11.3.3): Extracting archive
Created project in /var/www/repos/laravel-11x

laravel/laravelが管理されているgithubのレポからファイルをダウンロードしてlaravel-11xのディレクトリにインストールします。 Downloadingでは、ダウンロードされたファイルは直接larave-11xへのディレクトリには置かれません。将来のインストールを効率化するために、ユーザーのキャッシュのディレクトリにインストールされます。私のubuntuの環境では、ホームディレクトリの.cache/composerにファイルが置かれます。すでに同じバージョンのパッケージがあるなら、Downloadingは行われずに、そのキャッシュのディレクトリから、laravel-11xへのディレクトリにファイルがコピーされます。その作業がInstallingです。

.envの作成

> @php -r "file_exists('.env') || copy('.env.example', '.env');"

これは、composer.jsonの“scripts”セクションにあった、“post-root-package-install”のスクリプトですね。.env.exampleをコピーして.envを作成です。

composer.lockの作成

Loading composer repositories with package information
Updating dependencies
Lock file operations: 107 installs, 0 updates, 0 removals
  - Locking brick/math (0.12.1)
  - Locking carbonphp/carbon-doctrine-types (3.2.0)
...
Writing lock file

ここでは、composer.jsonの“require”と“require-dev”で指定されたパッケージたちのcomposer.jsonを読み、それらが依存するパッケージのcomposer.jsonも読み、コンフリクトがないようにインストールするすべてのパッケージとそのバージョンを決定します。そして、この時点で初めてcomposer.lockのファイルを作成して決定した情報を書き込みします。それがLockingの作業です。

“require”で指定したバージョンのデータと実際にダウンロードされるバージョンの違いに注意してください。例えば、“require"では、“laravel/framework”: “^11.9”とありますが、この時点では

...
- Locking laravel/framework (v11.34.2)
...

と、v11.34.2のバージョンがインストールされます。

依存するパッケージのインストール

Installing dependencies from lock file (including require-dev)
Package operations: 107 installs, 0 updates, 0 removals
  - Downloading doctrine/inflector (2.0.10)
  - Downloading doctrine/lexer (3.0.1)
...
  - Installing doctrine/inflector (2.0.10): Extracting archive
  - Installing doctrine/lexer (3.0.1): Extracting archive
...
41 package suggestions were added by new dependencies, use `composer suggest` to see details.

ここのステップでルートパッケージに依存するすべてのパッケージがcomposer.lockに従ったバージョンでlaravel-11x/vendorにインストールされます。DownloadingやInstallingはルートパッケージのところで説明したものと同様です。

scriptsの実行

Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
> @php artisan vendor:publish --tag=laravel-assets --ansi --force
> @php artisan key:generate --ansi
> @php -r "file_exists('database/database.sqlite') || touch('database/database.sqlite');"
> @php artisan migrate --graceful --ansi

残りの作業は、composer.jsonで指定されたイベントにマッチするスクリプトが実行されます。上から順番に以下のイベントとなります。

```
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ],
```
composer autoload-dumpを実行したときにも実行されますが、プロジェクトの初期化で使用される必要なパッケージとそのクラスのリストを含むファイルを作成します。
```
        "post-update-cmd": [
            "@php artisan vendor:publish --tag=laravel-assets --ansi --force"
        ],
```
プロジェクトで必要なアセットのファイルをパブリッシュします。上の経過では何もパブリッシュするものがなかったようです。

       "post-create-project-cmd": [
            "@php artisan key:generate --ansi",
            "@php -r \"file_exists('database/database.sqlite') || touch('database/database.sqlite');\"",
            "@php artisan migrate --graceful --ansi"
        ],

最後に、ここで.envのAPP_KEYの値を作成し、sqliteのデータベースのファイルを作成して、マイグレーションを実行します。

上は最新のLaravel 11.xですが、Laravel 10.xでは、

        "post-create-project-cmd": [
            "@php artisan key:generate --ansi"
        ]

となっていて、sqliteのデータベースの作成や設定は行いませんでした。

composerをもっと知ろう（１）composer show

Sat, 23 Nov 2024 06:51:48 +0900

composerは、phpのプロジェクトで使用されるパッケージを管理するコマンドです。昨今はcomposerなしではphpのプロジェクトは作成できないほど重要なものです。しかし、知らないことがたくさんあります。ということで「composerをもっと知ろう」シリーズです。composerに関するいろいろな面を紹介していきます。

composerがインストールしたパッケージ

まず、最新のLaravelのプロジェクトを作成してみましょう。

$ composer create-project laravel/laravel laravel-11x

composer create-projejtに関しては違う機会に説明するとして、上のコマンド実行後に何のパッケージがインストールされたか見てみましょう。

$ composer show

を実行すると、以下のように107ものパッケージのリストが、パッケージ名、バージョン、説明を列として表示されます。

brick/math                         0.12.1  Arbitrary-precision arithmetic library
carbonphp/carbon-doctrine-types    3.2.0   Types to use Carbon in Doctrine
dflydev/dot-access-data            3.0.3   Given a deep data structure, access data by dot notation.
doctrine/inflector                 2.0.10  PHP Doctrine Inflector is a small library that can perform string manipulations with regard to upper/lowercase and singular/plural forms of words.
doctrine/lexer                     3.0.1   PHP Doctrine Lexer parser library that can be used in Top-Down, Recursive Descent Parsers.
dragonmantank/cron-expression      3.4.0   CRON for PHP: Calculate the next or previous run date and determine if a CRON expression is due
egulias/email-validator            4.0.2   A library for validating emails against several RFCs
fakerphp/faker                     1.24.0  Faker is a PHP library that generates fake data for you.
filp/whoops                        2.16.0  php error handling for cool kids
fruitcake/php-cors                 1.3.0   Cross-origin resource sharing library for the Symfony HttpFoundation
graham-campbell/result-type        1.1.3   An Implementation Of The Result Type
guzzlehttp/guzzle                  7.9.2   Guzzle is a PHP HTTP client library
guzzlehttp/promises                2.0.4   Guzzle promises library
guzzlehttp/psr7                    2.7.0   PSR-7 message implementation that also provides common utility methods
guzzlehttp/uri-template            1.0.3   A polyfill class for uri_template of PHP
hamcrest/hamcrest-php              2.0.1   This is the PHP port of Hamcrest Matchers
laravel/framework                  11.31.0 The Laravel Framework.
laravel/pail                       1.2.1   Easily delve into your Laravel application's log files directly from the command line.
laravel/pint                       1.18.1  An opinionated code formatter for PHP.
laravel/prompts                    0.3.2   Add beautiful and user-friendly forms to your command-line applications.
laravel/sail                       1.38.0  Docker files for running a basic Laravel application.
laravel/serializable-closure       1.3.6   Laravel Serializable Closure provides an easy and secure way to serialize closures in PHP.
laravel/tinker                     2.10.0  Powerful REPL for the Laravel framework.
league/commonmark                  2.5.3   Highly-extensible PHP Markdown parser which fully supports the CommonMark spec and GitHub-Flavored Markdown (GFM)
..
続く

まだ開発を始めていなのにすでにこれだけのパッケージがインストールされます。上のリストを見ていて気付くのは、もちろんのことですが、Laravel自体もパッケージなのです。上のリストにあるlaravel/frameworkがそうです。他のもlaravelのレポからは６つのパッケージがインストールされます。私が大好きなlaravel/tinkerも含まれます。

composer.jsonの中身を見ればわかりますが、そこでは上のすべてのパッケージを指定はしていません。以下を実行すると指定したパッケージがリストされます。

$ composer show --self

上で、requiresの下にリストされているのが、ライブ環境で必要なパッケージです。phpはすでにインストールされているのでたったの２つです。 requires (dev)は、開発環境において必要なパッケージです。こちらもたったの７つです。

さて、どうしてcomposer showでは107ものパッケージがリストされるのでしょうか？

それは、requiresあるいはrequires (dev)でリストされているそれぞのパッケージがまた違うパッケージを必要とするからです。さらにそのパッケージもまた他のを…と。

例えば、私が好きなtinkerのパッケージを見てみましょう。

$ composer show --tree "laravel/tinker"

ツリー構造はtinkerのパッケージが依存するパッケージを表示します。

パッケージだけでなく、phpのバージョンやphpもモジュール（ext-json *など）の依存もあります。

composerはこれらを全部チェックして、すべてのをまとめて必要なパッケージをインストールします。それぞれパッケージは違うバージョンを指定することもあるので、バージョンの整合性もチェックする必要あります。非常に大変に複雑な作業です。composerの偉大さが理解できますね。

インストールされているパッケージは最新？

インストールしたパッケージたちは時間が経つと、バグの修正や新規のの追加など行われ、インストール時のバージョンと変わってきます。以下のコマンドは、最新のパッケージの情報を取得してきて見せてくれます。それゆえにコマンド実行には時間がかかります。

$ composer show --latest

それぞれの列は、パッケージ名、インストールされているバージョン、最新のバージョン、そして説明となります。最新のパージョンに列において緑字は「最新」であり更新の必要はないということで、赤字は更新を「推薦」という意味です。

黄色時は「メジャー」のバージョン更新がリリースされていることを示します。以下は違うプロジェクトからですが、前バージョンのLaravel 10xを使用しており、ご覧のようにLaravel 11xのメジャーリリースがあることを示しています。

先のプロジェクトに戻って、全部ではなく更新を推薦するパッケージのみを見たいなら以下を実行してください。–no-devのオプションは開発のパッケージを表示しません。

$ composer show --outdated --no-dev

composerでタスクを実行

Fri, 21 Aug 2020 00:19:34 +0900

先日、Laravel-boilerplateというオープンソースのプロジェクトのコードを見ていて、composerでプロジェクトのキャッシュのクリアー、ユニットテストの実行やコードの整形などいろいろなタスクを実行できることに気づきました。今回はその話です。

まっさらでインストールしたLaravelのプロジェクトでは、composer.jsonのscriptsのセクションは、以下のようになります。

composer.json

...
    "scripts": {
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ],
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate --ansi"
        ]
    }
}

上記のコマンドを説明すると、

post-autoload-dumpのタスクは、以下のようにdump-autoloadを実行したときに自動的に実行され、composer.jsonで指定されているパッケージの自動ディスカバーをしてくれます。昔のLaravelではこれいちいちconfig/app.phpファイルでのパッケージの指定していました。

$ composer dump-autoload
Generating optimized autoload files> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
Discovered Package: facade/ignition
Discovered Package: fideloper/proxy
Discovered Package: laravel/tinker
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.
Generated optimized autoload files containing 4218 classes

composer create-projectの実行でもこのスクリプトは実行されます。

post-root-package-installのタスクは、プロジェクト作成時において.envファイルがないときに実行され、.env.exampleから.envのファイルの作成します。

最後の、post-create-project-cmdのタスクは、これまたプロジェクト作成時に実行され、.envで使用される暗号キーを自動作成して.envに保存します。

さて、今度はlaravel-boilerplateのcomposer.jsonを見てみます。scriptsのセクションでは、上のデフォルトのスクリプトに付け加えて、いくつか独自のタスクのためのスクリプトを追加しています。以下では私が説明のためにコメントしていますが、jsonファイルはコメント指定不可なので注意を。

composer.json

...
    "scripts": {
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ],
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate --ansi"
        ],
        "post-update-cmd": [　// php stormなどのIDEエディターのヘルパーのため。
            "@php artisan ide-helper:generate",
            "@php artisan ide-helper:meta"
        ],
        "clear-all": [　// bootstrap/cacheやstorage/frameworkなどに含まれるキャッシュファイルを削除して、vendor/composer/autoload_real.phpを再作成
            "@php artisan clear-compiled",
            "@php artisan cache:clear",
            "@php artisan route:clear",
            "@php artisan view:clear",
            "@php artisan config:clear",
            "@php artisan permission:cache-reset",
            "composer dumpautoload -o"
        ],
        "cache-all": [ // 設定データやルートのデータをキャッシュ。bootstrap/cacheにキャッシュファイルを作成
            "@php artisan config:cache",
            "@php artisan route:cache"
        ],
        "reset": [ // composer関連のファイルをクリア
            "composer clear-all",
            "composer cache-all"
        ],
        "test": "vendor/bin/phpunit",　// ユニットテストの実行
        "test-coverage": "vendor/bin/phpunit --coverage-html coverage",　// ユニットテストのカバレージの作成
        "format": "vendor/bin/php-cs-fixer fix --allow-risky=yes"　// コードの整形
    }
}

最後に、追加されたスクリプトは、以下のように実行できます。

$ composer run clear-all

便利ですね。

紹介しておきながらなんですが、私はこれらのタスクは、Makefileに入れてmakeで実行します。それに関してはいつか紹介します。

composerのあれこれ

Mon, 17 Sep 2018 06:13:39 +0900

新規のLaravelのプロジェクトを作成するときや、ライブラリを追加するときに使用するcomposerのコマンド。Laravelの陰で一見地味な存在に見えます。しかし、このおかげでphp言語のライブラリのインフラが整備され、アプリのモダンな開発の基盤を提供しているなくてはならないコマンドです。今回はこのコマンドに注目してみます。

composerのインストール

1回実行すれば何もしないのですっかり忘れていたけれど、以下が正しいインストール方法。これによると。

$ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
$ php -r "if (hash_file('SHA384', 'composer-setup.php') === '544e09ee996cdf60ece3804abc52599c22b1f40f4323403c44d44fdfdd586475ca9813a858088ffbc1f233e9b180f061') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
$ php composer-setup.php
$ php -r "unlink('composer-setup.php');"

上を実行すると、composer.pharのファイルが作成されます。開発環境なら、自分のホームのbinのディレクトリに、グローバルで使用したいなら、ルート権限で以下のように適切なディレクトリへ移します。

$ mv composer.phar /usr/local/bin/composer

composer.pharの作成時には、ホームディレクトリに、.composerのディレクトリ（あるいは、.config/composer）が作成されます。

.composer
├── cache
├── keys.dev.pub
└── keys.tags.pub

今はほとんど空ですが、将来はすでにインストールしたパッケージのキャッシュやlaravelなどのコマンドの保存場所となります。

Laravelのパッケージのインストール

composerのコマンドが使えるようになったところで、laravelのパッケージをインストールします。

$ composer global require "laravel/installer"

globalのオプションは、ホームディレクトリの.composerのディレクトリにファイルをインストールすることを指定します。インストール後は、.composerのディレクトリは以下のような感じになります。

.composer
├── cache
│   ├── files
│   │   ├── guzzlehttp
│   │   ├── laravel
│   │   ├── psr
│   │   └── symfony
│   └── repo
│       └── https---repo.packagist.org
├── composer.json
├── composer.lock
├── keys.dev.pub
├── keys.tags.pub
└── vendor
    ├── autoload.php
    ├── bin
    │   └── laravel -> ../laravel/installer/laravel
    ├── composer
    ├── guzzlehttp
    ├── laravel
    │   └── installer
    ├── psr
    └── symfony

vendor/bin/laravelのコマンドに気づいたと思いますが、Laravelのプロジェクトの作成に使われるコマンドです。簡単に実行できるように、.bashrcなどのファイルにおいて、$PATHに、$HOME/.composer/vendor/binを追加しておいてください。

Laravelのプロジェクトの作成

ここまで来ると、プロジェクトの作成は簡単です。インストールしたいディレクトリへ行き以下を実行します。

$ laravel new new-project

注意が必要なのは、上のコマンドの実行では最新のLaravelのバージョン（今なら、5.7）がインストールされることです。

バージョンを指定したいなら、composerコマンドの登場です。

$ composer create-project --prefer-dist laravel/laravel new-project "5.5.*"

composerのオプション

新規のLaravelのプロジェクトを作成したところで、いったい何のパッケージがインストールされたのでしょう？ホームディレクトリの.composerと同様に、vendorのディレクトリを見るとパッケージに対応していろいろなディレクトリが作成されています。

パッケージの情報をより見たいなら、

composer show

の実行です。

$ composer show
beyondcode/laravel-dump-server        1.2.1    Symfony Var-Dump Server for Laravel
dnoegel/php-xdg-base-dir              0.1      implementation of xdg base directory specification for php
doctrine/inflector                    v1.3.0   Common String Manipulations with regard to casing and singular/plural rules.
doctrine/instantiator                 1.1.0    A small, lightweight utility to instantiate objects in PHP without invoking their constructors
doctrine/lexer                        v1.0.1   Base library for a lexer that can be used in Top-Down, Recursive Descent Parsers.
dragonmantank/cron-expression         v2.2.0   CRON for PHP: Calculate the next or previous run date and determine if a CRON expression is due
egulias/email-validator               2.1.5    A library for validating emails against several RFCs
erusev/parsedown                      1.7.1    Parser for Markdown.
fideloper/proxy                       4.0.0    Set trusted proxies for Laravel
filp/whoops                           2.2.1    php error handling for cool kids
fzaninotto/faker                      v1.8.0   Faker is a PHP library that generates fake data for you.
hamcrest/hamcrest-php                 v2.0.0   This is the PHP port of Hamcrest Matchers
jakub-onderka/php-console-color       0.1     
jakub-onderka/php-console-highlighter v0.3.2  
laravel/framework                     v5.7.3   The Laravel Framework.
laravel/tinker                        v1.0.7   Powerful REPL for the Laravel framework.
...

他のパッケージをインストールしたいなら、例えば、スプレッドシートのライブラリをインストールしたいなら、

composer require “phpoffice/phpspreadsheet”

を実行します。

composer.jsonのファイルも更新されて、“phpoffice/phpspreadsheet”: “^1.4”の行が追加されます。

{
    "name": "laravel/laravel",
    "description": "The Laravel Framework.",
    "keywords": ["framework", "laravel"],
    "license": "MIT",
    "type": "project",
    "require": {
        "php": "^7.1.3",
        "fideloper/proxy": "^4.0",
        "laravel/framework": "5.7.*",
        "laravel/tinker": "^1.0",
        "phpoffice/phpspreadsheet": "^1.4"
    },
...

開発のみに使用するパッケージは、

composer require barryvdh/laravel-debugbar –dev

と、–devオプションをつけて実行します。実行後は、composer.jsonのrequire-devセクションも以下のように更新されています。

...
    "require-dev": {
        "barryvdh/laravel-debugbar": "^3.2",
        "beyondcode/laravel-dump-server": "^1.0",
        "filp/whoops": "^2.0",
        "fzaninotto/faker": "^1.4",
        "mockery/mockery": "^1.0",
        "nunomaduro/collision": "^2.0",
        "phpunit/phpunit": "^7.0"
    },

...

手動でこのファイルを編集してパッケージを追加したときには、

composer update

を実行します。他のパッケージの更新やパッケージ間の依存のチェックもあり、時間がかかります。

上記のコマンドの実行で、composer.jsonが編集されることを見てきましたが、composer.lockというファイルも更新されます。このファイルは、プロジェクトのデプロイにおいて重要です。開発環境でテストされたプログラムと同じパッケージの同じパージョンを、本環境にプログラムをデプロイする必要あります。それには、

composer install

を本サイトで実行します。このコマンドは、composer.lockのデータに従って開発環境と同じパッケージの同じバージョンのファイルをインストールしてくれます。

さらに、

composer install –no-dev

と、–no-devオプションを付ければ、開発だけに必要なパッケージは一切インストールはしません。

composer.jsonとcomposer.lockはそれゆえに、gitなどで必ずバージョン管理する必要があります。