Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] True mirror registry #7912

Open
hyrious opened this issue Nov 15, 2024 · 0 comments
Open

[FEATURE] True mirror registry #7912

hyrious opened this issue Nov 15, 2024 · 0 comments

Comments

@hyrious
Copy link

hyrious commented Nov 15, 2024

Background

Currently the registry config affects the lockfile and fetch cache key, which affects anyone (including the CI, like github actions) working on the same project using the same registry to fetch dependencies. This behavior is correct, but seems beyond the mirror registry's purpose.

Here I want to distinguish a thing: There're 2 kinds of registries.

  • Mirror registry: serve as a copycat of the default registry. The fetch cache should always be the same as the default one.

    Note that many of them do not have an audit API endpoint ([BUG] npm audit fails with 404 error #4382), we may need another setting or hard-code the audit request. But in fact the audit step in install would timeout when people start using mirrors.

  • Private registry like npm.pkg.github.com. Private packages usually work under some scope name.

I know there's a config replace-registry-host=always which can always respect the registry setting from command line. But that seems a footgun and can't be treat as a default behavior.

Proposal

Therefore, I'm proposing a feature to separate the mirror usage out. For example mirror-registry=<url> or registry-is-mirror=true. When it is set, the arborist uses this config to fetch dependencies like what it currently does. But it writes out the default registry (https://registry.npmjs.org/) in the package-lock.json's resolved field.

Alternative

pnpm and deno, only write out a sha512 integrity in the lockfile. Maybe we can implement a package-lock.json v4 starting from here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant