Pull npm package from sub group/project
Problem to solve
As a developer, when I am using the NPM Registry, I need to be able to authenticate and upload packages at the sub-group level, so that I can effectively work within my team's project structure.
- Currently we only support project level authentication and upload for NPM.
- Larger organizations that rely on groups and subgroups are currently blocked from using the NPM Registry.
- This is inconsistent with our Maven Repository which allows for authentication and publishing at the group and instance level.
The goal of this issue is to drive adoption of the GitLab NPM Registry. Currently any user that is leveraging groups/sub-groups is blocked from using the feature. In addition, it we will start to create parity between our Maven and NPM registries.
Update the NPM Registry package name format to @root_namespace_path/any-name to allow for authentication and pulling packages at the group/sub-group level.
- Update the package publishing/creation logic to detect if there is a naming collision within the given namespace and return an error if there is.
- Update the installing/pulling logic to find a package by name instead of looking it up with the full path of the project, which under this model is no longer applicable.
- Enforce the scope to match the root namespace. For example, all projects and subgroups within
@gitlab-orgas their scope. The name after the scope can be anything but the docs will suggest using the project name if possible, and there is validation to be sure the same package name is not used twice in one scope.
Permissions and Security
- Reporters, Developers, Maintainers and Owners that have access to the group/sub-group should have access to pull from the NPM Registry.
- Developers, Maintainers, and Owners that have access to the group/sub-group should have access to publish to the NPM Registry.
- We will update NPM Registry documentation to include support for group/sub-group end-points and remove the top-level note that we do not currently support them. We will also include a warning about naming collisions, similar to how we message the issue in our Maven Repository documentation.
- We must ensure that the change does not break the existing project level endpoint for the NPM registry. Users must still be able to authenticate and publish at the project level.
- We must test the group and sub-group levels and ensure that it's working properly.
- Test with multiple permissions level and ensure there are no security violations with this enhancement.
What does success look like, and how can we measure that?
Success looks like we unlock usage of the NPM registry for users with groups and sub-groups. We have several customers asking for this functionality and we can test their use cases and ensure it's working for them. In addition, we should see an uptick in adoption and usage of the NPM Registry. We will test that by measuring the total number of NPM packages over time as well as the number of updates to the registry over time.
What is the type of buyer?
This impacts premium and ultimate customers the most as larger organizations are expected to require the usage of groups to better segment their teams and work.