### Problem to solve Currently, the GitLab npm registry allows you install packages from your project or the instance. But, as a GitLab SaaS user this doesn't really meet my needs. Why? Instance level would be too public and risk exposing sensitive information to a broader community. And the project level can be challenging because as an organization with many different projects, it requires a lot of configuration and leads to a poor developer experience. ### User experience goal Organizations with complex group/project hierarchies can use a group endpoint for the pulling of npm packages using a group deploy token. This will make it much easier to install npm packages without having to grant permissions to every developer for every project. ### Proposal Add a new endpoint to the npm registry that allows users to pull packages from their group. ### Further details To implement this one, we will need to: * Have a group level API class that includes *all* npm [endpoints](https://gitlab.com/gitlab-org/gitlab/-/blob/1ea3858a83503f3c4164449f09fe0eb3139d7a65/lib/api/concerns/packages/npm_endpoints.rb). * Please note that this will not only implement the endpoints needed for packages pulling. It will also implement the endpoints for tags and the bulk advisory. * Another thing to note, the [NPM request forward](https://docs.gitlab.com/ee/user/packages/npm_registry/#package-forwarding-to-npmjscom) should work as-is. * We will need to update how we find the [project](https://gitlab.com/gitlab-org/gitlab/-/blob/1ea3858a83503f3c4164449f09fe0eb3139d7a65/lib/api/helpers/packages/npm.rb#L18). * There is an ongoing change to gather *all* packages from a target namespace (see https://gitlab.com/gitlab-org/gitlab/-/issues/391692). That change is behind a ~"feature flag". As such, we need to support both code paths: 1. Using the project of the most recent package only. 1. Using the projects that have the related packages in the target namespace (well, in this case, the target group). * :warning: on permissions checks, we should follow what the ~"Maven Repository" is doing: 1. check for `read_group` on the target group. 1. check for `read_package` on the target project (should be already done by the npm endpoints) * This is to avoid situations like this [one](https://gitlab.com/gitlab-org/gitlab/-/issues/387286). * Create the related specs. NPM have a large amount of [shared rspec examples](https://gitlab.com/gitlab-org/gitlab/-/blob/1ea3858a83503f3c4164449f09fe0eb3139d7a65/spec/support/shared_examples/requests/api/npm_packages_shared_examples.rb) and we should be able to re-use that. * Update the related ~documentation to add anything related to group level endpoints. * We will need a review from @marcel.amirault for these changes. I don't see huge obstacles here but there is quite a chunky amount of changes. We might end up splitting this in several MRs which will take time. It might be wise to deploy this change behind a ~"feature flag" for an additional safety net. We have some changes that could end up hitting issues similar to https://gitlab.com/gitlab-org/gitlab/-/issues/391692#note_1333164048.