范围包注册表

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.

注意：如果您正在设置范围注册表指向具有受限访问权限的包注册表服务器，您可以配置 Package Manager 将您的 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:

Package Manager 决定从哪个注册表获取包时，会将包 name 的值与 scopes 的值进行比较，并找到 scopes 最匹配的注册表。

For example, in the project manifest below, there are two scoped registries, “Main” and “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"
    }
}

When the Package Manager looks up the com.example.animation package, it finds that the com.example.* namespace is the closest match to its name, and therefore fetches the package from the “Main” registry.

When the Package Manager looks up the com.example.tools.physics package, the “Tools” registry has a scope that exactly matches the package name.

When the Package Manager looks up the com.example.mycompany.tools.animation package, the Package Manager finds that the com.example.mycompany.tools.* namespace is the closest match to its name and therefore fetches the package from the “Tools” registry. Even though it also matches the “Main” scope, the com.example.* namespace is not as close a match.

当 Package Manager 查找 com.unity.animation 包时，在任何范围注册表中都找不到匹配项，因此从默认注册表获取该包。