Reputation: 15589
Artifactory supports NPM by creating local NPM registries.
The typical way to manage the packages is using NPM scope.
The Artifactory administrator can control who can publish to the registries.
How can the administrator controls who can publish to a specific NPM scope?
Creating multiple NPM registries in order to manage permissions could lead to conflicts. For example:
Team A owns and administrate https://<artifactory>/api/npm/npm-x
.
Team B owns and administrate https://<artifactory>/api/npm/npm-y
.
Both Team A and Team B independency decided to publish some packages under scope @my-company
.
Now Team C wants to use those packages from Team A and Team B.
They found that it is not possible because the resolution is ambiguous:
# .npmrc
# can not get package from Team B
@my-company:registry=https://<artifactory>/api/npm/npm-x
# can not get package from Team A
@my-company:registry=https://<artifactory>/api/npm/npm-y
# can it resolve correctly?
# what if both Team A and Team B publish a package named `@my-company/repo-scripts`?
registry=https://<artifactory>/api/npm/npm-virtual
Upvotes: 0
Views: 515
Reputation: 1554
This use-case can be solved either with separate repositories, or with a single repository. Both solutions rely on the ability to define include/exclude patterns. Artifactory has a very good permissions management system that can easily support this requirement.
Knowing that the file layout in an NPM repository always starts with the package name, you can use that knowledge and define an include pattern. For example, if team-A owns a scoped package named @my-company/team-a
, you can use the following include pattern:
@my-company/team-a/**
With a single repository, this can be done by creating a group for each team, and then granting each group permissions on the repository. The permissions of each team shall be limited to path prefix(es) in that repository, based on the scope(s) that team owns.
With multiple repositories, the permissions can be granted for each team (group) on their own repository, no need for include/exclude patterns. Instead, the repository can be configured to accept only files which match include/exclude patterns. If you choose to use multiple repositories, you can create a virtual repository that aggregates the local repositories. This way, clients only need to use a single registry which gives an abstraction on top the other registries.
For more information, please refer to the Artifactory documentation:
Upvotes: 3