YII2 のコンポーザーを通じてベンダーを最適化する方法

次のコラム composer 使用法チュートリアル では、YII2 が Composer を通じてベンダーを最適化する方法を紹介します。

この記事では、Yii2 フレームワークをインストールし、コンポーザー ツールを使用してベンダーを最適化するプロセスで遭遇する問題について説明します。読者は基本原則をある程度理解していることに同意します。コンポーザーの資格を持ち、Yii2 フレームワークのインストールに関する実務経験があること。

Yii2 コミュニティでは、公式に推奨されているバージョンをインストールした後、ある種の問題がよく発生します。

1 なぜベンダー フォルダがないのですか?

Yii2 では、vendor は、composer によってダウンロードされる依存ライブラリ ファイルです。公式プロジェクト テンプレート コードには、独自のプロジェクト ファイルのみがあり、yii フレームワークとそれが依存する他のクラス ライブラリはすべて、composer.json に記録されます。 Composer をインストールしてから、インストールまたは更新するだけです。

2 私が自分でインストールした Yii2 プロジェクトでは、ベンダーのパッケージがcomposer.json に見つからず、これらのパッケージのほとんどは当面は必要ありません。どうすればそれらを削除して、ベンダーは最小化されましたか？

検証済みのシナリオ

2.1 パッケージを削除するには、composer Remove を使用します。

削除されたパッケージは、vendor フォルダーの下の Composer.json に記録され、パッケージの削除後に削除される必要があります。同時に、すべてのパッケージが再インストールされます。

2.2 パッケージを削除するには、composer update --no-dev を使用します。

開発モードのパッケージは直接削除されます。削除後、プロジェクトを実行すると、エラーが直接報告されます。したがって、すべての開発モード パッケージを削除することはできません

2.3 パッケージを削除するには、remove codeception/verify を使用します。ほとんどのパッケージはテスト モードです。私の過去の開発経験によれば、単体テストに関連するコンポーネントは使用されていないため、remove codeception/verify コマンドを使用して Yii2 コンポーザー パッケージを合理化できます。このコマンドは、composer パッケージの最適化の重要な部分です。

3 1 つのプロジェクトの下に複数のプロジェクトがある場合、初めてロードされるコンポーザー パッケージが多すぎるため、ロード パフォーマンスの問題が発生しますか? 組み込みの遅延読み込みでこの問題は解決できますか?

プロジェクトに明らかに不要なコンポーネントは直接削除できますが、パフォーマンスへの影響については、まだ遭遇していません。遅延読み込みはフレームワーク レベルの最適化であると考えられており、私はその機能を信じることにしました。

4 ベンダー パスの問題が原因でディレクトリまたはファイルが存在しないというプロンプトが表示される

プロジェクト パスが次であると仮定します。 E:sourcestemplates

Vendor パスに問題がある場合、次のような同様の問題が発生します。つまり、特定の Composer パッケージが存在しないということです。

Invalid Parameter – yiibaseInvalidParamException
The file or directory to be published does not exist: E:sourcestemplatesbackendvendorbower-asset/jquery/dist

ファイル パッケージが存在しないことは、単なる症状であり、主な原因は、ベンダー パスとプロジェクト構成ファイルが対応していないことです。

プロジェクトのメイン設定ファイル main.php の下に、ベンダーの設定エントリがあります。VendorPath の特定の値は、設定ファイルのパスと組み合わせる必要があります。次の 2 つを参照してください。画像と関連するパス構成

最初の画像

'vendorPath' => dirname(dirname(__DIR__)) . '/vendor',

2 番目の画像

'vendorPath' => dirname(dirname(dirname(__DIR__))) . '/vendor',

概要:

compser を使用する場合は、次の 3 つの問題を考慮する必要があります

1 Composer のインストールと Composer のアップデートの違い

2 Composer のバージョン管理と安定性

3 公開コンポーザー パッケージの形式でコンポーネントを出力および保守する方法

##次のコマンドの違いについては、ネットワーク情報集を参照してください

composer install

が最も重要です。一般的に使用されるコマンドです。Composer は、ローカルのcomposer.json インストール パッケージに基づいてパッケージをダウンロードします。パッケージをプロジェクトの下のベンダー ディレクトリに置き、インストール中にパッケージのバージョン情報をcomposer.lockに入れてバージョンをロックします。

実際には、インストール中に、composer.lock のバージョンが現在のバージョンと同じであることが判明した場合、vendor ディレクトリ内のコード バージョンが一貫している場合、Composer は何も行いません。composer.lock の目的は、次のことを可能にすることです。パッケージの最新バージョンを入手しなくても、現在のバージョンで安心して作業できます。

composer update

composer .lock ファイル内のパッケージ バージョンが更新され、composer.json に記録されたパッケージが更新されます。最新のものに更新されました。

composer update コマンドは注意して使用する必要があります。

コンポーザーを使用してコンポーネントがプロジェクト内で参照され、パブリック コンポーネントになった場合、コンポーザー コマンドの使用には注意が必要です。当然、メンテナンスには専任の担当者が必要であり、共有コンポーネントはありません。操作権限。

コンポーザーの使用法チュートリアルの詳細については、

composer コマンドの使用法グラフィック チュートリアル 列を参照してください。

以上がYII2 のコンポーザーを通じてベンダーを最適化する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。