Uh oh!
There was an error while loading. Please reload this page.
implement options affecting resolved value in lock files. - #4264
Closed
everett1992 wants to merge 3 commits into
Closed
implement options affecting resolved value in lock files.#4264everett1992 wants to merge 3 commits into
resolved value in lock files.#4264everett1992 wants to merge 3 commits into
Conversation
everett1992force-pushed
the
remove-registry-resolve
branch
from
January 19, 2022 23:31
6feb42a to
16b54e9Compare1 task
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`.
Create shrinkwrap files with resolved urls modified to replace the configured registry with the default registry, https://registry.npmjs.org. The default registry is a magic value meaning the current registry, so recording resolved with the default registry allows users to switch to a different registry without removing their lockfile. The path portion of the acutal resolved url is preserved so this trick only works when the different registries host tarballs at the same relative paths. It's faster than the omitLockfileRegistryResolved option because npm doesn't need to fetch each pacument to resolve the tarball url.
everett1992force-pushed
the
remove-registry-resolve
branch
from
April 4, 2022 21:55
16b54e9 to
99de719Compare
This was referenced Apr 13, 2022
darcyclarke
commented
Apr 20, 2022
Contributor
Removing |
nlf
commented
Aug 2, 2022
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR implements two options that affect t he
resolvedvalue in lock files described in npm/rfcs#486. There are more details in the RFC but the gist is that the lock file records information from the registry used when packages were added to the lock file. This can cause undesired behaviors including install failures when changing the configured registry.This is very much a work in progress and I'm eager for any feedback, especially the names of the options, alternate solutions to these problems, and how I've plumbed 'options' thru the Shrinkwrap class.
omit-lockfile-registry-resolvedThis option omits the resolved value from the registry. On subsequent installs npm will resolve the tarball url from the registry. This supports any kind of registry, and guarantees the registry is the authority on the location of tarballs, but makes installs slower.
record-default-registryThis option uses the magic properties of the default registry
https://registry.npmjs.com. When the lockfile is read npm replaces the default registry with the currently configured registry. This magic behavior allows users to switch from the default registry to a custom registry - but you can't switch from a custom registry to another registry once a custom registry is recorded in a lock file.This option does the opposite transform of the magic default, replacing the custom registry with the default registry when recording the lock file.
There were other proposals to record lock files with a sigil that explicitly means 'the current registry'
But this isn't cross compatible with other npm versions or clients. This option effectively uses
https://registry.npmjs.comas that sigil, which is compatible with earlier versions of npm.The main downside with this option is that the lockfile records the path portion of the resolved url which can change between registries. This option only supports switching between registries that host tarballs at the same relative path. This downside is already present in npm's magic handling of the default registry.
The other downside is that it hangs more weight on the magic behavior of the default registry.
References
Related to npm/rfcs#486