ホームページ  >  記事  >  開発ツール  >  レビュー作成者

レビュー作成者

藏色散人
藏色散人転載
2020-12-02 15:07:452018ブラウズ

次のチュートリアル コラムでは、composer について説明し、composer について確認していきます。困っている友人の役に立てば幸いです。

レビュー作成者

#Composer は、PHP コミュニティによって推奨されている依存関係管理ツールです。 Composer は PHP にとって、npm は Node にとってのようなもので、現代の PHP 開発にはほぼ必須のスキルです。この記事では、Composer の関連概念と使用法を簡単に説明します。

拡張機能とパッケージ

関連する概念はフレームワークとライブラリです。フレームワークとライブラリの違いについては、以前に書いたこの記事を参照してください。

拡張機能とパッケージ2 つは非常によく似た概念です。 PHP の世界では、この 2 つは一般的に次のように理解され区別されます: エクステンションとモジュールは同等であり、C 言語で書かれた関数のコレクションです; パッケージとライブラリは同等で、主に C 言語で書かれています。 PHP によって実装される関数の一部であり、拡張機能はダイナミック リンク ライブラリ (dll など) の形式でロードされ、パッケージは require/include を通じてロードされます。ほとんどの場合、この 2 つを混合しても理解が困難になることはありません。

一般的な拡張機能には、GD、ZIP、XML、MySQLi、OPCache などが含まれます。一般的なパッケージには、PHPMailer、PHPOffice、HTMLPurifier などが含まれます。

PEAR と PECL

Composer が普及する前は、PEAR と PECL の 2 つのツール (コミュニティ) が PHP 開発者によく知られていました。 PEAR は PHP Extension and Application Repository の略で、公式 Web サイトは http://pear.php.net、PECL は PHP Extension Community Library の略で、公式 Web サイトは http://pecl.php.net です。

この 2 つの違いは拡張機能とパッケージによって区別できます: PECL ホスティング拡張機能、ソース コードは主に APC、AMPQ などの C ファイルです; PEAR ホスティング パッケージ、機能は PHP で実装されます。 PHP CodeSniffer、HTTP Request など。;PEAR は pear コマンドに対応し、PECL は pecl コマンドに対応します。これら 2 つのコマンドを使用して、拡張機能とパッケージをインストールおよび管理できます (pear の build/pickleサブコマンドは PECL で拡張機能をコンパイルすることもできます)。二人はお互いを補い合っており、公式サイトでは姉妹のような関係であると説明されている。

PECL は公式拡張の補足であり、現在もアクティブであり、いくつかの優れた拡張は公式拡張となる可能性があります。ハン・ティエンフェン・マスターのスウール拡張もPECLでホストされており、中国では非常によく知られています。それに比べれば、PEAR は過去のものです。 PEAR2 と Pyrus (PHP5.3 に基づいて構築された次世代 PEAR パッケージ インストール ツール、公式 Web サイト http://pear2.php.net) の登場により、PEAR を救うことができなくなりました。 PEAR の衰退に伴い、この記事の主人公である Composer が台頭します。

PEAR は「再利用可能な PHP コンポーネントを提供する」という位置づけで、開発者に機能パッケージを一元的に提供します。集中リリース方式はコードの品質は確保できるものの、レビューに合格したパッケージしかリリースできないためメンテナンスに不便があり、パッケージの陳腐化現象も深刻です。 PEAR によってインストールされるパッケージはグローバルであり、依存パッケージをプロジェクトごとにインストールすることはできません。権限のないユーザーが依存パッケージを自分でインストールすることはできません。その他の欠点としては、依存関係の管理が不十分であることが挙げられます。 Github の人気と Composer の登場により、パッケージ管理は Composer の時代に入りました。 PEARは歴史的使命を終えましたので、安心してご利用いただけます。

Composer

厳密に言えば、Composer はパッケージ マネージャーではなく、依存関係管理ツールとして位置付けられます。 Composer の中国語 Web サイトでは、Composer の働きを次のように紹介しています:

Composer は次のように問題を解決します:

a) いくつかのライブラリに依存するプロジェクトがあります。

b) これらのライブラリの一部は他のライブラリに依存しています。

c) あなたは何に依存しているかを宣言します。

d) Composer は、どのバージョンのパッケージをインストールする必要があるかを判断し、それらをインストールします (プロジェクトにダウンロードします)。

Composer は、PEAR で実行できることはすべて実行できます (PECL 拡張機能のインストールを含む)。 Composer はデフォルトでパッケージをプロジェクト ディレクトリにインストールし、通常のユーザーはそれを通常どおり使用できます (Composer は公式に、root として Composer コマンドを実行しないことを推奨しています)。ベスト プラクティス (つまり、有名な PSR 仕様。詳細については、 PHP-FIG 公式 Web サイト https://www.php-fig.org) は、PHP コミュニティでのコーディング スタイルの標準化を大幅に促進します。Composer は、誰でもコード パッケージを公開できる分散型プラットフォームです。 PEAR の後継として、Composer のパフォーマンスはコミュニティのテストに耐え、依存関係管理の事実上の標準ツールとなっています。

Composer は現在巨大なエコシステムを形成しており、量の点では Composer のパッケージは PEAR をはるかに上回っています。誰でもレビューなしで自由にパッケージを公開できるため、Composer エコシステム内のパッケージには、不均一なコード品質、さまざまなコード スタイル、バックドアの脆弱性などの隠れた懸念がある可能性があります。さらに、Composer の依存関係管理はプロジェクトに基づいており、同じパッケージがマシンに複数回インストールされる可能性があります。全体として、Composer は PHP 開発エコシステムを大きく変え、コード交換とコミュニティ開発を促進しました。

Composer の使用法

Composer はプロジェクトの依存関係を管理するために生まれており、プロジェクト内の Composer.json ファイルがその作業の基礎となります。ファイルの最も重要な部分は、Composer にインストールする予定のパッケージとそのバージョンを通知する require セクションです。例:

{
    "name": "tlanyan/foo",
    "version": "1.0.0",
    ....
    "require": {
        "php": ">=5.4.0",
        "yiisoft/yii2": ">=2.0.6",
        "yiisoft/yii2-swiftmailer": "*",
        "yiisoft/yii2-redis": ">=2.0.0",
        "smarty/smarty": "< =3.1.25",
        "yiisoft/yii2-smarty": ">=2.0.0",
        "phpoffice/phpexcel": ">=1.8.0",
        "tecnickcom/tcpdf": "~6.2.0"
    },
    ....
}

然后运行composer install命令,Composer会自动分析依赖,安装最合适的包到vendor目录下。加-v(-vv, -vvv)选项会打印命令执行过程中的详细信息。安装完毕后,vendor目录下会生成autoload.php文件。在项目的入口文件中包含此文件: require __DIR__ . "/vendor/autoload.php";,接下来便可在项目的任何地方引用依赖包中的接口和类。

install命令,Composer提供了许多其他命令管理依赖。常用的命令场景包括:查找依赖、引入依赖、安装依赖、更新依赖。分别对应的命令是:

  1. composer search: 根据关键字查找依赖包,例如查找本人发布的包:composer search tlanyan。该命令等同于上https://packagist.org进行包查找;
  2. composer require: 引入依赖,声明项目或者全局(global,用户名全局,非系统全局)依赖某个包, 例如声明需要swiftmailer包: composer require [global] "swiftmailer/swiftmailer:dev-master";该命令更新composer.json文件,并默认立即安装依赖(--no-update选项可阻止默认安装);效果等同于编辑composer.json文件,然后执行install命令;
  3. composer install:安装composer.json声明的依赖包,最终安装的依赖包版本可能取决于有无composer.lock文件;
  4. composer update: 更新依赖到最新版本,相当于删除composer.lock文件后执行composer install

以上四条命令涵盖使用Composer的大部分场景。以下是几个常用的辅助命令,与依赖分析相关:

  1. composer info: 查看安装的依赖包信息,与composer show等价;
  2. composer dumpautoload: 加-o选项可导出优化的加载器;
  3. composer why(-not): 查看(不)安装某个包的原因。

总结

从拷贝第三方代码到项目中(1994),到PEAR安装依赖包(1999),再到Composer兴起(2012),PHP社区经历了将近20年的探索。PHP这门古老的语言,也在不断的发展更新,在web领域一直发光发热。Composer作为目前PHP包依赖管理的最佳工具,值得每一位PHP开发人员掌握。

以上がレビュー作成者の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はsegmentfault.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。