A scoped registry allows you to use a custom registry where you can host your own packages, in addition to the Unity registry. This is the same concept that npm uses. Using scoped registries ensures that the Package Manager always maps a package to one and only one registry, guaranteeing a consistent result regardless of network conditions.
일부 조직은 폐쇄된 네트워크 내부에서 작업하기 때문에 Unity의 자체 패키지 레지스트리에 액세스하기 어렵습니다. 이러한 경우 조직은 폐쇄된 네트워크 내부의 서버에 자체 패키지 레지스트리를 설정할 수 있습니다. 그런 다음 네트워크 관리자는 주기적으로 Unity의 패키지 레지스트리와 동기화하여 범위 지정 레지스트리에 사용 가능한 최신 패키지 집합이 있는지 확인할 수 있습니다.
In some cases, developers want to provide their own custom modifications to standard Unity packages to their customers in a single, reliable location. Examples of these include creating custom toolbar or menu items for a Unity package, or extending the tools provided in a Unity package to interface better with their own custom package.
Custom package providers put their custom Unity packages on a package registry server. A package registry server is an application that keeps track of packages and provides a place to store them. A scoped registry communicates the location of the custom package registry server to Unity so that the user has a seamless experience where the custom package overrides the Unity package without the user having to manually install the set of custom packages.
This document explains how a package consumer can set up their Unity project to use an existing custom package registry server. If you are a package producer, see Sharing your package to find out which package registry servers are supported and links to information on how to set them up to use with scoped registries.
참고: 액세스가 제한된 패키지 레지스트리 서버를 가리키는 범위 지정 레지스트리를 설정하는 경우 npm 인증 토큰을 서버에 전달하도록 패키지 관리자를 설정할 수 있습니다. 자세한 내용은 범위 지정 레지스트리 인증을 참조하십시오.
To set up your scoped registries in your project manifest, use the scopedRegistries property, which takes an array of scoped registry configuration objects. Each object contains a name, a url location, and a list of scopes for each package name pattern you want to map to that scoped registry:
프로퍼티 | JSON 타입 | 설명 |
---|---|---|
name | String | 사용자 인터페이스에 표시되는 범위 이름입니다. Package Manager 창의 패키지 세부 정보 뷰에 이 이름이 표시됩니다. 예: "name": "Tools" . |
url | String |
npm 호환 레지스트리의 URL입니다. 예: "url": "https://mycompany.example.com/tools-registry"
|
scopes | 문자열 배열 | 패키지 이름과 정확히 일치하는 항목 또는 네임스페이스로 패키지 이름에 매핑할 수 있는 범위 배열입니다. 예: "scopes": [ "com.example", "com.example.tools.physics" ] 참고: 이 타입의 설정은 패키지가 역순 도메인 이름 표기법을 준수한다고 가정합니다. 따라서 com.unity 는 com.unity.* 와 동일하게 간주됩니다. |
패키지 관리자는 패키지를 페치할 레지스트리를 결정할 때 패키지 이름을 범위 값과 비교한 후 범위가 가장 가깝게 일치하는 레지스트리를 찾습니다.
예를 들어 아래의 프로젝트 매니페스트에는 두 개의 범위 지정 레지스트리, 즉 “Main”과 “Tools”가 있습니다.
{
"scopedRegistries": [
{
"name": "Main",
"url": "https://example.com/registry",
"scopes": [
"com.example", "com.example.tools.physics"
]
},
{
"name": "Tools",
"url": "https://mycompany.example.com/tools-registry",
"scopes": [
"com.example.mycompany.tools"
]
}
],
"dependencies": {
"com.unity.animation": "1.0.0",
"com.example.mycompany.tools.animation": "1.0.0",
"com.example.tools.physics": "1.0.0",
"com.example.animation": "1.0.0"
}
}
패키지 관리자는 com.example.animation
패키지를 조회할 때 com.example.*
네임스페이스가 해당 이름과 가장 일치하는지 확인한 후 “Main” 레지스트리에서 해당 패키지를 페치합니다.
패키지 관리자는 com.example.tools.physics
패키지를 조회할 때 “Tools” 레지스트리에는 패키지 이름과 정확히 일치하는 범위가 있습니다.
패키지 관리자는 com.example.mycompany.tools.animation
패키지를 조회할 때 com.example.mycompany.tools.*
네임스페이스가 해당 이름과 가장 일치하는지 확인한 후 “Tools” 레지스트리에서 패키지를 페치합니다. “Main” 범위와 일치하더라도 com.example.*
네임스페이스는 가까운 매치가 아닙니다.
패키지 관리자는 com.unity.animation
패키지를 조회할 때 범위 지정 레지스트리에서 일치하는 항목을 찾지 않으며, 기본 레지스트리에서 패키지를 페치합니다.