Mastering Composer：使用のヒントとコツ

Habrahabrの読者に、Bruno Skvorcによる記事「Mastering Composer-Tips and Tricks」の翻訳を提供します。







Composerは、PHPのパッケージ管理に革命をもたらし、世界中の開発者がフレームワークに依存しない共有コードを作成するのに役立ちました。 それでも、その機能の基本を超えるものはほとんどないため、この記事では、その使用の便利なトリックをいくつか取り上げます。

グローバルインストール（グローバル）

このオプションはドキュメントに記載されているという事実にもかかわらず、Composerはグローバルにインストールできます（ほとんどの場合、そうすべきです）。 グローバルインストールとは、次の代わりに：

php composer.phar somecommand
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

任意のプロジェクトに簡単に入力できます。

 composer somecommand
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、ファイルシステムの任意の場所に新しいプロジェクトを簡単に作成できます（たとえば、 create-projectコマンドを使用）。



Composerをグローバルにインストールするには、次の手順に従ってください 。

依存関係の正しいインストール

入門書やREADMEファイルを読むと、多くの人が次のように書いてくれます。

composer.json ファイルに以下を追加するだけです ：

 {
     「必須」：{
         「myproject」：「someversion」
     }
 }

しかし、このアプローチにはいくつかの欠点があります。 まず、単純なコピーアンドペーストはエラーにつながる可能性があります。 第二に、初心者にとっては、すでに広範なcomposer.jsonファイルがある場合、このコードを配置する場所が明確ではない可能性があり、これもエラーにつながります。 最後に、Composerを初めて使用する人もいれば、コマンドラインを初めて使用する人もいます。 したがって、初心者が不安を感じる可能性のあるあらゆる種類のケースをカバーすることをお勧めします（グラフィックエディターを持っているか、コマンドラインを使用しますか？2番目の場合、テキストエディターがインストールされていますか？ファイルの編集手順？そして、composer.jsonファイルがプロジェクトにまだ存在しない場合はどうなりますか？また、新しいファイルを作成する原理を説明していますか？）。



composer.jsonファイルに新しい依存関係を追加する最良の方法は、 requireコマンドを使用することです 。

 composer require somepackage/somepackage:someversion
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、必要なものすべてが依存ファイルに追加され、手動の介入がバイパスされます。



require-devセクションにパッケージを追加する必要がある場合、 コマンドに--devオプションを追加します。

 composer require phpunit/phpunit --dev
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、 requireコマンドは、複数のパッケージを同時に追加することをサポートしています。これにより、スペースで区切るだけです。

ファイルをロックする

composer.lockファイルは、インストールされている依存関係とそのバージョンの現在のリストを保存します。 そうすれば、依存関係のバージョンが既に更新されている場合、プロジェクトを複製する他の人は同じバージョンを取得できます。 これにより、プロジェクトを受け取るすべての人が、開発中に使用したものと同じ「バッチ環境」を持っていることを確認でき、バージョンのアップグレードによって発生する可能性のあるエラーを回避できます。



composer.lockファイルは、 ほとんどの場合バージョン管理システムに追加する必要があります（ 常にではありません ）。



また、 composer.lockファイルにはcomposer.jsonファイルのハッシュが含まれているため、プロジェクトの作成者に関する情報を更新しただけでも、ロックファイルが.jsonファイルと一致しないという警告が表示されます。 この場合、 composer update --lockコマンドが役立ちます。このコマンドは、他に何も触れずに、ロックファイル自体のみを更新します。

バージョニング

有効なパッケージバージョンを指定する場合、正確な対応（ 1.2.3 ）、比較演算子の範囲（ <1.2.3 ）、これらの演算子の組み合わせ（ > 1.2.3 <1.3 ）、「最終利用可能」（ 1.2。* ）、チルダ記号を使用できます（ 〜1.2.3 ）および挿入マーク（ ^ 1.2.3 ）。



最後の2つの方向には、個別の説明が必要です。

• セマンティックバージョン管理ではこれが新しい機能を導入する瞬間であるため、チルダ（ 〜1.2.3 ）の指示には1.3までのすべてのバージョンが含まれます（包括的ではありません）。 この場合、最後の安定したマイナーバージョンが取得されます。 ドキュメントによると、この表示では、バージョンの最後の桁のみを変更できます。
• 挿入マーク（ ^ 1.2.3 ）は文字通り「重大な変更のみに注意する」ことを意味し、 2.0までのバージョンが含まれます 。 semverとの関係では、メジャーバージョンの変更はプロジェクトに重要な変更を加える瞬間です。したがって、バージョン1.3、1.4、および1.9が適切ですが、 2.0はもう存在しません。

特定のバージョンのパッケージが必要であることがわかっていない限り、常に最も安全な選択肢である〜1.2.3形式を使用することをお勧めします。

ローカルおよびグローバル構成

デフォルト値は石に刻まれていません。 可能な構成パラメーター（ config ）の詳細な説明については、 リンクを参照してください 。



たとえば、次を指定します。

 {
     「config」：{
         「optimize-autoloader」：true
     }
 }

Composerに、各インストールまたはパッケージの更新後にクラスマップを最適化するよう強制します（つまり、クラスの自動ロードファイルが生成されるたびに）。 これはデフォルトのオートローダーを作成するよりもわずかに遅く、プロジェクトが大きくなるにつれて遅くなります。



別の便利なオプションはcache-files-maxsizeです。 大規模なプロジェクト（eZ PublishやSymfonyなど）では、キャッシュがすぐにいっぱいになる可能性があります。 キャッシュサイズを大きくすると、Composerの動作が長くなります。



構成パラメーターはグローバルに設定できることに注意してください。この場合、それらはすべてのプロジェクトに影響します（ configを参照）。 たとえば、キャッシュサイズパラメータをグローバルに設定するには、 〜/ .composer / config.jsonファイルを編集するか、次を実行する必要があります。

 composer config --global cache-files-maxsize "2048MiB"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロファイリングと詳細出力

コマンドラインでComposerを使用しているときにコマンドに--profileオプションを追加すると、出力には最終結果だけが含まれるわけではありません。例：

 [174.6MB/54.70s] Memory usage: 174.58MB (peak: 513.47MB), time: 54.7s
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、出力の各行の先頭には、コマンドの実行時間と使用されるメモリサイズが追加されます。

 [175.9MB/54.64s] Installing assets for Sensio\Bundle\DistributionBundle into web/bundles/sensiodistribution
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このオプションを使用して、「遅い」パッケージを識別し、PHPの異なるバージョン間でパフォーマンスの向上またはパフォーマンスの低下を監視します 。



前のオプションと同様に、 -verboseオプションを使用すると、Composerは実行されている各操作に関する詳細情報を表示し、何が起こっているかを正確に知ることができます。 composer --verbose --profileをデフォルトのcomposerコマンドエイリアスに設定する人もいます。

カスタムソース

プロジェクトがまだPackagistにない場合は、GitHubからパッケージをインストールするだけでよい場合があります（たとえば、パッケージがまだ開発中の場合）。 これについては、マニュアルを参照してください 。



プロジェクトが依存する人気のあるパッケージの独自のバージョンがある場合、カスタムソースをインラインエイリアシングと組み合わせて使用​​して、パブリックパッケージの代わりに独自のブランチを使用できます（Matthieu Napoliがここで説明します） 。

Speeding Composer

Mark Van Eijkによって説明された優れた方法を使用すると、HHVMを介して起動することでComposerを高速化できます。



別の方法は、 -prefer-distパラメーターを使用することです。Composerをインストールすると、バージョン管理システムからクローンを作成する代わりに、安定したパッケージバージョンのプロジェクトがダウンロードされます（非常に遅い）。 このオプションはデフォルトで使用されるため、安定したプロジェクトで有効にする必要はありません。 ソースからプロジェクトをダウンロードする必要がある場合は、 -prefer-sourceオプションを使用します。 詳細については、 インストールセクションをご覧ください 。

Composerプロジェクトのサイズを縮小する

Composerに優しいプロジェクトの開発者であれば、この部分にも興味があります。 このRedditの投稿では、 .gitattributesファイルを使用して、 -prefer-distモードのパッケージパッケージング中に一部のファイルとフォルダーを無視できます。

 / docs export-ignore
 / export-ignoreをテストします
 /.gitattributes export-ignore
 /.gitignore export-ignore
 /.travis.yml export-ignore
 /phpunit.xml export-ignore

どのように機能しますか？ プロジェクトをGitHubにアップロードすると、 「zipのダウンロード」リンクが自動的に使用可能になり、プロジェクトのアーカイブをダウンロードできます。 さらに、Packagistはこれらの自動生成されたアーカイブを使用して--prefer-distオプションを使用して依存関係をダウンロードし、ローカルで解凍します（プロジェクトソースファイルのクローンを作成するよりもはるかに高速です）。 プロジェクトのロジックに関連しないテスト、ドキュメント、およびその他のファイルを.gitattributesに追加すると 、これらのアーカイブにはそれらが含まれなくなり、はるかに簡単になります。



同時に、ライブラリをデバッグしたりテストを実行したい人は--prefer-sourceパラメーターを指定する必要があります。



PhpLeagueはこのアプローチを採用し、それを「 パッケージスケルトン 」に含めたため、それに基づいたプロジェクトはすべて自動的に「dist friendly」になります。

ショー

使用しているPHPまたはその拡張機能のバージョンを突然忘れた場合、またはインストールされているすべてのプロジェクト（それぞれの説明を含む）のバージョンのリストが必要な場合は、 showコマンドを--platform （ -p ）および--installed （ -i ）：

リハーサル（ドライラン）

新しい依存関係のインストールが成功したかどうかを確認するには、 インストールおよび更新コマンドに--dry-runオプションを使用できます。 この場合、Composerは、コマンド自体を直接実行せずに、潜在的な問題をすべて表示します。 プロジェクトに実際の変更は発生しません。 この手法は、複雑な依存関係をテストし、実際に変更する前に変更を設定するのに最適です。

 composer update --dry-run --profile --verbose
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクト作成

最後になりましたが、言及する必要があるのはcreate-project コマンドです。



プロジェクト作成チームは、パッケージ名を引数として使用し、パッケージ内でcomposer installを複製して実行します。 これはプロジェクトの初期化に最適です-GitHubで必要なパッケージのUrlを検索し、クローンを作成し、自分でフォルダに移動してインストールコマンドを実行する必要がなくなりました。



SymfonyやLaravelなどの大規模プロジェクトでは、すでにこのアプローチを使用してスケルトンアプリケーションを初期化しており、他の多くのプロジェクトも参加しています。



たとえば、Laravelでは、これは次のように使用されます。

 composer create-project laravel/laravel --prefer-dist --profile --verbose
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに2つのパラメーターをcreate-projectコマンドに渡すことができます。プロジェクトをインストールする必要があるパス （指定しない場合、パッケージ名が使用されます）、およびバージョン （指定しない場合は後者が使用されます）。

おわりに

このヒントとコツのリストがお役に立てば幸いです。 何か見逃した場合は、そのことをお知らせください。記事を更新します。 コマンドやオプションを忘れた場合は、 チートシートをご覧ください 。 幸せな作曲！