Unity でプロジェクトをロードするときに、Unity Package Manager はプロジェクトマニフェストを読み込み、ロードするパッケージのリストを計算します。ユーザーが Package Manager ウィンドウからパッケージをインストールまたはアンインストールすると、それらの変更は Package Manager によってプロジェクトマニフェストファイルに保存されます。プロジェクトマニフェストファイルは依存関係のオブジェクトを通してパッケージのリストを管理します。
さらに、プロジェクトマニフェストは Package Manager の構成ファイルとしても機能します。Package Manager はマニフェストを使用してレジストリ URL をカスタマイズし、カスタムレジストリを登録します。
manifest.json というプロジェクトマニフェストファイルが、Unity プロジェクトの root フォルダー下の Packages フォルダー内にあります。パッケージマニフェストファイルと同様に、プロジェクトマニフェストファイルは JSON (JavaScript Object Notation) 構文を使用します。
すべてのプロパティは任意です。ただし、プロジェクトマニフェストファイルに値がまったく含まれていない場合、Package Manager ウィンドウは起動せず、Package Manager はパッケージをロードしません。
| キー | JSON 型 | 説明 |
|---|---|---|
| 依存関係 | オブジェクト | プロジェクトに必要なパッケージのコレクションで、直接の依存関係のみが含まれます (間接的な依存関係はパッケージマニフェストにリストされています)。各エントリーは、パッケージ名をプロジェクトに必要な最小のバージョンにマップします。{"dependencies": {"com.my-package": "2.3.1","com.my-other-package": "1.0.1-preview.1",etc.}}バージョン番号を指定すると、Package Manager はパッケージレジストリからパッケージをダウンロードします (つまり、パッケージのソースはレジストリです)。ただし、バージョンの使用に加えて、ローカルフォルダーや .tgz ファイル、または Git URL へのパスを指定することもできます。 ノート: 埋め込まれたパッケージは、Package Manager によってプロジェクトの Packages フォルダー内で検索され、自動的にロードされるため、ここで指定する必要はありません。Package Manager は、自身のパッケージマニフェストに同じ名前の埋め込まれたパッケージがある場合、そのようなエントリーをすべて無視します。 |
| enableLockFile | ブーリアン | ロックファイルを有効にして、依存関係を決定論的に解決します。デフォルトでは、この値は true に設定されています。詳細については、ロックファイルの使用を参照してください。 |
| resolutionStrategy | 文字列 | セマンティックバージョニングのルールに基づいて、間接的な依存関係をアップグレードします。デフォルトでは、この値は lowest に設定されています。詳細については、後述の解決法の設定を参照してください。 |
| scopedRegistries | オブジェクトの配列 | デフォルトのレジストリに加えて、カスタムのレジストリを指定します。これにより、独自のパッケージをホストすることができます。 詳細については、スコープ付きレジストリを参照してください。 |
| testables | 文字列の配列 | Unity Test Framework にロードするテストのパッケージ名をリストします。詳細は、パッケージにテストを追加を参照してください。 ノート: 埋め込まれたパッケージは、Unity Test Framework にデフォルトでテスト可能であるとみなされるため、指定する必要はありません。 |
{
"scopedRegistries": [{
"name": "My internal registry",
"url": "https://my.internal.registry.com",
"scopes": [
"com.company"
]
}],
"dependencies": {
"com.unity.package-1": "1.0.0",
"com.unity.package-2": "2.0.0",
"com.company.my-package": "3.0.0",
"com.unity.my-local-package": "file:<path>/my_package_folder",
"com.unity.my-local-tarball": "file:<path>/my_package_tarball.tgz",
"com.unity.my-git-package": "https://my.repository/my-package.git#v1.2.3"
},
"enableLockFile": true,
"resolutionStrategy": "highestMinor",
"testables": [ "com.unity.package-1", "com.unity.package-2" ]
}
間接的な依存関係は、プロジェクトマニフェストに明示的に追加することで、Unity のパッケージ依存関係の解決でのより高いバージョンの使用を強制することができますが、これは次の 2 つの理由から、あまり良い方法ではありません。
より良い方法は、resolutionStrategy プロパティを設定することで、Package Manager がセマンティックバージョニングのルールに基づいて間接的な依存関係を選択する仕組みをカスタマイズすることです。
| 値 | 説明: |
|---|---|
| lowest | 間接的な依存関係をアップグレードせず、その代わりに要求されたバージョンをそのまま使用します。これがデフォルトのモードです。 |
| HighPatch | 同じメジャーコンポーネントとマイナーコンポーネントを持つ最高のバージョンにアップグレードします。例えば、必要なバージョンが 1.2.3 の場合、この方法では [1.2.3, 1.3.0) の範囲内 (つまり、>= 1.2.3 かつ < 1.3.0) で、最も高いバージョンが選択されます。 |
| HighestMinor | 同じメジャーコンポーネントを持つ最高のバージョンにアップグレードします。例えば、必要なバージョンが 1.2.3 の場合、この方法では [1.2.3, 2.0.0) の範囲内 (つまり、>= 1.2.3 かつ < 2.0.0) で、最も高いバージョンが選択されます。ノート: バージョン 1.0.0 は、安定した本番環境が可能な最初のバージョンを示しています。それより下のバージョン 0.X.Y は、その API がまだ安定していないことを示しており、続くマイナーバージョンでは破壊的変更が発生する可能性があります。セマンティックバージョニングの仕様のこの部分は、迅速な開発を妨げることなくパッケージの初期バージョンをリリースすることを可能にしています。このため、ターゲットバージョンが 0.X.Y の場合、highestMinor は highestPatch のように動作し、後方互換性のあるバージョンの選択を保証します。例えば、要求されたバージョンが 0.1.3 の場合、[0.1.3,0.2.0) の範囲で最も高いバージョンが選択されます。 |
| highest | 最高のバージョンにアップグレードします。例えば、必要なバージョンが 1.2.3 の場合、この方法では [1.2.3,) の範囲 (つまり、>= 1.2.3 かつ上限なし) で最高バージョンを選択します。 |
ノート: これらの範囲によって、依存関係が安定リリースから実験的リリースまたはプレリリースのパッケージに移行することはありません。