Unity がプロジェクトをロードするときに、Unity Package Manager はプロジェクトマニフェストを読み込み、ロードするパッケージのリストを計算します。ユーザーが Package Manager ウィンドウ からパッケージをインストールまたはアンインストールすると、Package Manager はそれらの変更をプロジェクトマニフェストファイルに保存します。プロジェクトマニフェストファイルは 依存関係 オブジェクトを通してパッケージのリストを管理します。
さらに、プロジェクトマニフェストは Package Manager の構成ファイルとしても機能します。Package Manager はマニフェストを使用してレジストリ URL をカスタマイズし、カスタムレジストリを登録します。
manifest.json というプロジェクトマニフェストファイルは Unity プロジェクトのルートフォルダー下の Packages フォルダー内にあります。パッケージマニフェストファイルと同様に、プロジェクトマニフェストファイルは JSON (JavaScript Object Notation) 構文を使用します。
すべてのプロパティは必須ではありません。ただし、プロジェクトマニフェストファイルに値がまったく含まれていない場合、Package Manager ウィンドウは起動せず、Package Manager はパッケージをロードしません。
| キー | JSON 型 | 説明 |
|---|---|---|
| ** の依存関係** | オブジェクト | プロジェクトに必要なパッケージのコレクション。これには、直接の依存関係のみが含まれています (間接的な依存関係は、パッケージマニフェスト に記載されています)。各エントリーは、パッケージ名 を、プロジェクトに必要な最低限の バージョン にマップします。{<br /> “com.my-package”: “2.3.1”,<br /> “com.my-other-package”: “1.0.1-preview.1”,<br /> etc.<br /> }<br />}<br /><br />バージョン番号を指定することは、Package Manager がパッケージレジストリからパッケージをダウンロードすることを意味します (つまり、パッケージの [ソース](upm-concepts.html#Sources) はレジストリです)。ただし、[バージョン](upm-manifestPkg.html#version) を使用するだけでなく、[ローカルフォルダーや .tgz ファイルへのパス](upm-localpath.html) や [Git URL](upm-git.html) を指定することもできます。<br /><br />**ノート**: Package Manager は、自動的に [埋め込み](upm-embed.html) パッケージをプロジェクトのPackagesフォルダー内で見つけてロードするので、パッケージを指定する必要はありません。Package Manager は、それ自体のパッケージマニフェストに同じ [名前](upm-manifestPkg.html#name) の埋め込みパッケージがある場合、どのエントリーも無視します。 |
| <a name="enableLockFile"></a>**enableLockFile** | ブーリアン | ロックファイルを有効にして、依存関係を決定論的に解決します。これは、デフォルトではtrueに設定されています。詳細については、[ロックファイルの使用](upm-conflicts-auto.html) を参照してください。 |
| <a name="resolutionStrategy"></a>**resolutionStrategy** | 文字列 | セマンティックバージョニングのルールに基づいて、[間接的な依存関係](upm-dependencies.html) をアップグレードします。これは、デフォルトでは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, 2.0.0] の範囲 (つまり、>= 1.2.3 かつ上限なし) で最高バージョンを選択します。 |
ノート: これらの範囲によって、依存関係が安定したリリースから 実験版 パッケージまたは プレリリース パッケージに移動されることはありません。