-
Notifications
You must be signed in to change notification settings - Fork 239
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
Resolved registry overrides #486
base: main
Are you sure you want to change the base?
Conversation
We can take this off the agenda tho I'd appreciate implementation input from someone familiar with package-lock and arborist. I think How do I tell if a node was resolved from a registry or a literal http dependency? |
Start npm/rfcs#486. This implements `$disable-write-resolves` without creating an option. Next I'll figure out how to plumb a npm config option thru to shrinkwrap.
Start npm/rfcs#486. This implements `$disable-write-resolves` without creating an option. Next I'll figure out how to plumb a npm config option thru to shrinkwrap.
Implement `$disable-write-resolves` described in npm/rfcs#486. I named the option `omitLockfileRegistryResolved` but that can be changed later. Put simply, this option causes npm to create lock files without a `resolved` key for registry dependencies forcing npm to use the current configured registry and resolve package tarball urls on install. This fixes install errors when users change registries and the recorded resolved url is incorrect. This option causes slower installs because npm must fetch each packages manifest to find the tarball url, but it's the most comprehensive solution to this problem. Options like recording always the default registry, or recording a special 'current registry' sigil will break if registries host tarballs at different paths. For example `${REGISTRY}/npm/-/npm-8.3.0.tgz` only works if all registries host tarballs at `npm/-/npm-8.3.0.tgz`.
I've drafted this RFC in npm/arborist#352. Has there been more discussion including registry in lockfile? I think omitting resolved is the most comprehensive option because it supports switching between registries that host tarballs at different paths. But that makes it also more expensive than other options because npm must re-resolve the tarball url from package manifest. So I'm considering alternatives Maybe npm could guess that a dependency without Maybe we implement this RFC and an option that supports switching between registries that host tarballs at the same path without paying the resolve cost. @isaacs mentioned wanting to use a sigil to mean 'the current registry', such as We need to replace the registry part of the resolved url with
We could work backward from the package name and registry config. We need the name because scopes can use different registries. |
Implement `$disable-write-resolves` described in npm/rfcs#486. I named the option `omitLockfileRegistryResolved` but that can be changed later. Put simply, this option causes npm to create lock files without a `resolved` key for registry dependencies forcing npm to use the current configured registry and resolve package tarball urls on install. This fixes install errors when users change registries and the recorded resolved url is incorrect. This option causes slower installs because npm must fetch each packages manifest to find the tarball url, but it's the most comprehensive solution to this problem. Options like recording always the default registry, or recording a special 'current registry' sigil will break if registries host tarballs at different paths. For example `${REGISTRY}/npm/-/npm-8.3.0.tgz` only works if all registries host tarballs at `npm/-/npm-8.3.0.tgz`.
@darcyclarke would you add this to the agenda for the next RFC meeting? The PR implementing this RFC has a Needs Discussion tag. |
Implement `$disable-write-resolves` described in npm/rfcs#486. I named the option `omitLockfileRegistryResolved` but that can be changed later. Put simply, this option causes npm to create lock files without a `resolved` key for registry dependencies forcing npm to use the current configured registry and resolve package tarball urls on install. This fixes install errors when users change registries and the recorded resolved url is incorrect. This option causes slower installs because npm must fetch each packages manifest to find the tarball url, but it's the most comprehensive solution to this problem. Options like recording always the default registry, or recording a special 'current registry' sigil will break if registries host tarballs at different paths. For example `${REGISTRY}/npm/-/npm-8.3.0.tgz` only works if all registries host tarballs at `npm/-/npm-8.3.0.tgz`.
Removing the |
Create a mechanism that allows users to create package-locks that can be used with different custom registries.
link to rfc