Unity가 프로젝트를 로드할 때 Unity 패키지 관리자는 검색해서 가져온 후 로드할 패키지 리스트를 계산하기 위해 프로젝트 매니페스트를 읽습니다. 사용자가 Package Manager 창을 통해 패키지를 설치하거나 제거하면 패키지 관리자는 그러한 변경 사항을 프로젝트 매니페스트 파일에 저장합니다. 프로젝트 매니페스트 파일은 dependencies 오브젝트를 통해 패키지 리스트를 관리합니다.
또한 프로젝트 매니페스트는 매니페스트를 사용하여 레지스트리 URL을 커스터마이즈하고 커스텀 레지스트리를 등록하는 패키지 관리자의 설정 파일 역할을 합니다.
Unity 프로젝트의 루트 폴더 아래에 있는 Packages 폴더에서 manifest.json이라는 이름의 프로젝트 매니페스트 파일을 찾을 수 있습니다. 패키지 매니페스트 파일과 마찬가지로 프로젝트 매니페스트 파일은 JSON(JavaScript Object Notation) 구문을 사용합니다.
모든 프로퍼티는 선택 사항입니다. 하지만 프로젝트 매니페스트 파일에 아무런 값도 없으면 Package Manager 창이 로드되지 않고 패키지 관리자가 아무 패키지도 로드하지 않습니다.
팁: 언제든지 메인 Unity 도움말 메뉴에서 Reset packages to defaults를 선택하여 레지스트리 관련 문제를 해결할 수 있습니다. 하지만 이 작업은 프로젝트의 종속성에 적용한 모든 변경 사항을 재설정하므로 최후 수단으로만 사용해야 합니다.
| Key | JSON 타입 | 설명 |
|---|---|---|
| dependencies | 오브젝트 | 프로젝트에 필요한 패키지 컬렉션입니다. 여기에는 직접 종속성만 포함됩니다(간접 종속성은 패키지 매니페스트에 나열됨). 각 항목은 패키지 이름을 프로젝트에 필요한 최소 버전에 매핑합니다. {"dependencies": {"com.my-package": "2.3.1","com.my-other-package": "1.0.1-preview.1",etc.}}버전 숫자를 지정하면 패키지 관리자에게 패키지 레지스트리에서 해당 패키지를 다운로드하기를 원함을 알립니다(즉 패키지의 소스가 레지스트리임). 하지만 버전을 사용하는 것 외에도 로컬 폴더 또는 타르볼 파일 경로나 Git URL을 지정할 수도 있습니다. 참고: 여기에서 내장 패키지를 지정할 필요는 없습니다. 패키지 관리자는 프로젝트의 Packages 폴더에서 이러한 패키지를 찾아 자동으로 로드합니다. 자체 패키지 매니페스트에 이름이 동일한 내장 패키지가 있는 경우 패키지 관리자는 모든 항목을 무시합니다. |
| enableLockFile | 부울 | 잠금 파일을 사용하여 종속성이 결정론적 방식으로 해결되도록 합니다. 기본적으로 true로 설정됩니다. 자세한 내용은 잠금 파일 사용을 참조하십시오. |
| resolutionStrategy | String | 유의적 버전 규칙에 따라 간접 종속성을 업그레이드합니다. 기본적으로 lowest로 설정됩니다. 자세한 내용은 아래의 해결 전략 설정을 참조하십시오. |
| scopedRegistries | 오브젝트 배열 | 기본 레지스트리 외에 커스텀 레지스트리를 지정하여 자체 패키지를 호스트할 수 있습니다. 자세한 내용은 범위 지정 레지스트리를 참조하십시오. |
| testables | 문자열 배열 | Unity 테스트 프레임워크에 테스트를 로드하려는 패키지 이름을 나열합니다. 자세한 내용은 패키지에 테스트 추가를 참조하십시오. 참고: 여기에서 내장 패키지를 지정할 필요는 없습니다. Unity 테스트 프레임워크는 기본적으로 테스트가 가능하다고 가정합니다. |
{
"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의 패키지 종속성 해결을 오버라이드하여 간접 종속성을 업그레이드할 수 있지만, 이는 다음의 두 가지 이유로 좋은 전략은 아닙니다.
더 나은 접근 방식은 패키지 관리자가 resolutionStrategy 프로퍼티를 설정하여 유의적 버전 규칙에 따라 간접 종속성을 선택하는 방식을 커스터마이즈하는 것입니다.
| Value: | 설명: |
|---|---|
| lowest | 간접 종속성을 업그레이드하지 않고, 요청된 버전을 사용합니다. 기본 모드입니다. |
| highestPatch | 동일한 Major 및 Minor 컴포넌트가 있는 가장 높은 버전으로 업그레이드합니다. 예를 들어 요청된 버전이 1.2.3인 경우 이 전략은 [1.2.3, 1.3.0) 범위(즉 >= 1.2.3 및 < 1.3.0)에서 가장 높은 버전을 선택합니다. |
| highestMinor | 동일한 Major 컴포넌트가 있는 가장 높은 버전으로 업그레이드합니다. 예를 들어 요청된 버전이 1.2.3인 경우 이 전략은 [1.2.3, 2.0.0) 범위(즉 >= 1.2.3 및 < 2.0.0)에서 가장 높은 버전을 선택합니다.참고: 버전 1.0.0은 프로덕션 준비를 마친 최초의 안정된 버전을 나타냅니다. 그 아래의 버전 0.X.Y는 API가 아직 안정적이지 않으며 연속적인 마이너 버전을 통해 중대한 변경 사항이 도입될 수 있음을 의미합니다. SemVer 사양의 이러한 부분을 이용하면 신속한 개발을 방해하지 않고 패키지의 초기 버전을 릴리스할 수 있습니다. 이러한 이유로 타겟 버전이 0.X.Y이면 highestMinor는 이전 버전과 호환되는 버전을 선택하기 위해 highestPatch처럼 작동합니다. 예를 들어 요청된 버전 0.1.3인 경우 이 전략은 [0.1.3,0.2.0) 범위에서 가장 높은 버전을 선택합니다. |
| highest | 가장 높은 버전으로 업그레이드합니다. 예를 들어 요청된 버전이 1.2.3인 경우 이 전략은 [1.2.3) 범위(즉 >= 1.2.3, 상한 없음)에서 가장 높은 버전을 선택합니다. |
Note: These ranges never allow a dependency to jump from a stable release to an experimental or pre-release package.