Version: 2019.4
Accessing package assets
Resolution and conflict

Scoped Registries

Scoped Registries allow Unity to communicate the location of any custom package registry server to the Package Manager so that the user has access to several collections of packages at the same time. Here are some important concepts to help you understand this feature:

Concept: Description:
package registry server An application that keeps track of packages and provides a place to store them. In Unity’s Package Manager window, all packages registered on Unity’s registry appear in the list view when you select the Unity Registry context.
package manager An application that tells the user what is available, and downloads and installs whatever package the user requests for their project. Unity has implemented its own version of a package manager, but there are several similar applications in other organizations.
scope Defines a package name or namespace (in reverse domain format), such as com.example.mycompany.animation or com.example. When a user requests a package, the Package Manager fetches the package from the registry that best matches the scope. For more information, see Managing scoped registries for a project below.


Package providers set up custom registry servers to host and distribute custom packages in addition to the Unity registry. Package consumers set up scoped registries for each project in order to access a custom package provider’s registry server.

Scoped Registries can help to:

  • Provide new functionality by distributing tools, libraries, and other assets.

    As a provider, you can create your own registry to distribute tools and scriptsA piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info
    See in Glossary
    (or other types of assets) with version numbers that indicate how mature the package is, or whether updates introduce breaking API changes or minor fixes: Semantic Versioning. And your code can depend on code in other packages because the Package Manager supports package dependencies.

    As a consumer, your experience of browsing and installing third-party custom packages in the Package Manager is the same as for Unity’s packages.

  • Extend existing Unity’s package features.

    As a consumer, you can have a seamless experience where the custom package overrides the Unity package without the having to manually switch registries or explicitly install a different package version. This is because you can map packages to a specific registry so that Package Manager fetches from either the Unity registry or a custom package registry server.

  • Access packages in a closed network environment.

    Some organizations work inside a closed network, which makes it difficult to access Unity’s own package registry. In these cases, the organization can set up their own package registry on a server inside their closed network. The network administrators can then periodically synchronize with Unity’s package registry to make sure the scoped registry has the latest set of packages available.

If you are a package consumer, see Setting up a scoped registry to find out how to connect to an existing custom package registry server in your Unity project. 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.

Note: If you are setting up a scoped registry that points to a package registry server with restricted access, you can configure Package Manager to pass your npm authentication token to the server. For more information, see Scoped registry authentication.

Setting up a scoped registry

To set up your scoped registries in your project manifestEach Unity project has a project manifest, which acts as an entry point for the Package Manager. This file must be available in the <project>/Packages directory. The Package Manager uses it to configure many things, including a list of dependencies for that project, as well as any package repository to query for packages. More info
See in Glossary
, 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:

Property JSON Type Description
name String The scope name as it appears in the user interface. The Package Manager window displays this name in the package details view.

For example, "name": "Tools".
url String The URL to the npm-compatible registry server.

For example, "url": "https://mycompany.example.com/tools-registry"
scopes Array of Strings Array of scopes that you can map to a package name, either as an exact match on the package name, or as a namespace. Wildcards and other glob patterns are not supported.

For example, "scopes": [ "com.example", "com.example.tools.physics" ]

Note: This type of configuration assumes that packages follow the Reverse domain name notation. This ensures that com.unity is equivalent to any package name that matches the com.unity namespace, such as com.unity.timeline or com.unity.2d.animation.

Warning: Unity does not support npm’s @scope notation.

When the Package Manager decides which registry to fetch a package from, it compares the package name to the scopes values and finds the registry whose scopes most closely match.

For example, in the project manifest below, there are two scoped registries, “General” and “Tools”:

{
    "scopedRegistries": [
        {
            "name": "General",
            "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 “General” 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 “General” scope, the com.example namespace is not as close a match.

When the Package Manager looks up the com.unity.animation package, the Package Manager doesn’t find a match in any of the scoped registries, and therefore fetches the package from the default registry.


Accessing package assets
Resolution and conflict