-
Notifications
You must be signed in to change notification settings - Fork 246
Open
Description
Motivation ("The Why")
The current .npmrc
configuration model allows specifying only one registry per scope, which is too limiting for more complex setups.
Example
We use a self-hosted GitLab instance as our internal NPM registry provider. GitLab supports publishing packages at different levels:
- Project-level registry — each project has its own NPM registry.
- Group-level registry — a registry that aggregates all packages from child projects in the group.
- Instance-level (global) registry — exposes packages using the group name as the scope, and the project name as the package name.
Suppose we have the following structure:
project-a
published to:https://gitlab.example.com/api/v4/projects/1/packages/npm/
libraries/*
packages published to:https://gitlab.example.com/api/v4/groups/6/-/packages/npm/
This setup introduces limitations for consumers:
- We want to use a single shared scope, such as
@our-org/*
, across all packages in our organization. - Some packages are published to project-level registries, while others use group-level registries.
References
- Related/Reference to [RRFC] npmrc file improvements. #427
Metadata
Metadata
Assignees
Labels
No labels