Example - Multiple upstreams for a registry

Connecting several different package sources to a registry

What if your team or organization wants to use packages from different sources without setting up and using more than one registry?

Bytesafe supports multiple configured upstreams for each registry where the priority of the upstreams decides the order in which they are queried for package versions.

This is beneficial for several use-cases where users want to keep the main package source but also:

  • Connect additional registries that contain patched versions of public packages - overruling package versions from the main package source
  • Connect additional registries that contain private packages - both third party and internal
  • Connect Git repositories - containing single packages

Example: Determining package source from multiple upstreams - using priority order

graph TD
  A(fab:fa-npm registry.npmjs.org) --> | prio 2 | B{Bytesafe registry};
  C(third-party registry) --> | prio 1 | B;
  B --> | install | D[fa:fa-user Project workspace];

If both upstreams contain the same package version that is required by the Bytesafe registry, the information will be pulled from the one with the highest priority (starting with priority 1).


How it works

Registries with multiple upstreams implicitly have a priority order for those upstreams. Unless altered by the user, upstreams are automatically assigned a descending priority order when added.

When a developer pulls a package version from a registry, all connected upstreams will be queried for available versions. If the Bytesafe registry does not already contain the package, the developer will be served with the package version from the highest priority upstream that contains the information.

Resulting in:

  • If the upstreams contain different package universes there will be only one package source and priority has no impact.
  • If multiple registries contain the same package versions (or patched versions of packages) priority will determine the package source.

Assuming the desired behavior for your project is to always trust and prioritize one source over others and/or include patched versions from specific upstreams, upstream priority will remove manual steps to ensure you receive package versions from the intended source.