文物通过创建本地NPM注册表来支持NPM。
管理软件包的典型方法是使用 npm范围。
文物管理员可以控制谁可以发布给注册表。
管理员如何控制谁能发布到特定的NPM范围？
创建多个NPM注册机构以管理权限可能导致冲突。例如：
A团队拥有和管理 https：//＆lt; artifactory＆gt;/api/npm/npm/npm-x </code>。
B团队拥有并管理 https：//＆lt; trifactory＆gt;/api/npm/npm/npm-y 。
A团队和B团队独立性都决定在Scope @My-Company 下发布一些软件包。
现在，C团队想使用A团队和B队的这些软件包。
他们发现这是不可能的，因为该分辨率模棱两可：
# .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
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
发布评论
评论（1）
可以使用单独的存储库或单个存储库来解决此用例。两种解决方案都取决于定义的能力包括/排除模式。文物具有非常好的权限管理系统，可以轻松支持此要求。
知道NPM存储库中的文件布局始终从软件包名称开始，您可以使用该知识并定义包含模式。例如，如果Team-A拥有一个名为
@my-Company/team-A的示波器软件包，则可以使用以下模式：使用单个存储库，这可以可以通过为每个团队创建一个小组，然后授予每个组。每个团队的权限应限于该存储库中的路径前缀，并根据团队拥有的范围。
有了多个存储库，可以在自己的存储库中为每个团队（组）授予权限，无需包含/排除模式。取而代之的是，仅可以接受接受匹配的文件包括/排除模式。
如果选择使用多个存储库，则可以创建
有关更多信息，请参阅文档文档：
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: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: