Replies: 1 comment
-
Hi there @RoyTinker and welcome to our community! Thank you for asking a great question 🙂 To get started, introduce yourself in our official introduction thread |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello, we have a front-end team that is just about to publish a new React internal UI library via GitHub Packages.
Our Problem
The internal name of the library is Flow UI, and we're distributing it as a collection of packages. We want our internal customers to reference our library in their package.json files like so:
We also have a few other packages we'll be publishing, like
@flow-ui/dropdowns
.But with GitHub Packages, we're running into a problem. It looks like the only package scope allowed is derived from our GitHub Organization -
@floqastinc
. Unfortunately, given this restriction, the most sensible package naming scheme possible looks like:etc.
Requested feature
We'd love if GitHub packages could support arbitrary package names -- if we could publish to any name internally, whether or not it conflicts with a package on the public
npmjs.com
repo.This would solve our problem by lifting the restriction that prevents publishing using a scope other than
@floqastinc
.(Note: if arbitrary package names creates the risk of NPM substitution attacks, how about allowing an organization to add additional package scopes? This would also solve the problem we're having.)
Other problems this would solve
Allowing arbitrary package names would enable companies or individuals to create and use private versions of public packages. Companies or individuals may wish to add a feature or fix a bug (or security issue) without the burden of publishing the change back to the original source (which may not wish to accept the change, may not be maintaining the project, or may have contribution rules/requirements in place that the company or individual cannot meet).
Caveats
Use of arbitrary package names does require setting npm/yarn up locally to request all packages from GitHub Packages, not just those from a particular scope. GitHub Packages would need to function as a proxy to
npmjs.com
's registry (for all packages not published by the org associated with the authenticated user) -- which it may not be fully capable of at the moment (the docs aren't clear either way).Use of arbitrary package names could open the way for NPM substitution attacks if/when developers don't have NPM correctly configured. However, note that scope squatting is still a risk, especially via creating organizations on npmjs.com that directly correspond to GitHub orgs that publish internal packages.
Third-party tools
Verdaccio is an excellent npmjs-proxying package manager. It supports publishing to arbitrary package names, and even shadowing public versions of those packages.
GitLab Package Registry does not currently support arbitrary npm package names: https://docs.gitlab.com/ee/user/packages/npm_registry/
Beta Was this translation helpful? Give feedback.
All reactions