Allow configuration of publish restrictions

[knksmith57]

This is a Feature Proposal

Description

Currently, attempting to publish a package that exists on the public registry will always fail. This restriction makes sense if we assume that users should (or only want to) store unique packages in codebox and intend to proxy all other requests to the global registry.

I'm new here and not sure if this assumption is intentional and/or a desirable characteristic of this registry solution in particular. If so, please allow me to convince you of a few good reasons to allow configuration of this restriction:

1. overriding or patching public packages. deprecated, poorly maintained, and abandoned packages are all too common on the public registry and pose a huge risk to operational security and stability. allowing organizations to publish new (or override existing) versions of public packages is a good way to mitigate that risk.
2. limiting published packages to certain scopes. organizations may wish to enforce, at the registry level, which scope(s) are eligible for private hosting. this is useful when developers opt to only associate the private registry with certain scope(s) or if an organization needs to maintain several registries, each responsible for a discrete scope(s).
3. deprecating private scopes. very similar to # 2, organizations migrating from an existing private registry solution may wish to continue to provide read-only access to a legacy scoped package and also disable publishing new packages to that same scope.

A naive implementation that would satisfy # 2 & # 3 could be accomplished by adding a new environment variable (eg: CODEBOX_RESTRICTED_SCOPES) formatted as a comma-delimited list of permissible scopes. A simple membership check of this list before the existing unique check should be sufficient.

# 1 quickly becomes non-trivial if the ability to override at the version level is desired as existing checks and processes are limited to the package level.

What do y'all think?

[jonsharratt]

Thanks for raising this, you are correct the current use case is by intention. As it stands we do not allow admins to publish under the same name as public npm.

The core reason is security, to stop engineers in large organisations that have publish rights the ability to inject a module in place of a well known one such as say babel.

It could cause havoc in build pipelines with some nasty outcomes. I think for me at least it may well be better to enforce scopes for the private registry so that they can not be mixed with public packages.

I will have a think a bit more in regards to your options and get back to you.