Conversation
…ndard URLs When lockfile-include-tarball-url is explicitly set to false, tarball URLs are now always excluded from the lockfile. Previously, packages hosted under non-standard tarball URLs would still have their tarball field written to the lockfile even when the setting was false, causing flaky and inconsistent behavior across environments. The fix makes the option tri-state internally: - true: always include tarball URLs - false: never include tarball URLs - undefined (not set): use the existing heuristic that includes tarball URLs only for packages with non-standard registry URLs Fixes pnpm#6667
|
💖 Thanks for opening this pull request! 💖 |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a long-standing issue where the lockfile-include-tarball-url=false setting was not fully respected. When set to false, packages hosted under non-standard tarball URLs (e.g., npm Enterprise installations) would still have their tarball field written to pnpm-lock.yaml, causing flaky behavior, merge conflicts, and CI failures.
Changes:
- Made
lockfileIncludeTarballUrltri-state internally:true(always include),false(never include), andundefined(use heuristic based on URL standard-ness) - Removed the default
falsevalue so the option isundefinedwhen not explicitly set, preserving the existing heuristic behavior as the default - Added explicit check for
lockfileIncludeTarballUrl === falsethat bypasses the non-standard URL heuristic
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
pkg-manager/resolve-dependencies/src/updateLockfile.ts |
Added explicit check to exclude tarball URLs when option is false, before the non-standard URL heuristic |
pkg-manager/core/src/install/extendInstallOptions.ts |
Changed lockfileIncludeTarballUrl type to optional and removed default value |
pkg-manager/core/test/lockfile.ts |
Added tests verifying tarball URLs are excluded for both standard and non-standard packages when option is false |
.changeset/fix-lockfile-include-tarball-url.md |
Added changeset documenting the fix |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
zkochan
approved these changes
Feb 25, 2026
|
Congrats on merging your first pull request! 🎉🎉🎉 |
zkochan
pushed a commit
that referenced
this pull request
Mar 7, 2026
…ndard URLs (#10621) When lockfile-include-tarball-url is explicitly set to false, tarball URLs are now always excluded from the lockfile. Previously, packages hosted under non-standard tarball URLs would still have their tarball field written to the lockfile even when the setting was false, causing flaky and inconsistent behavior across environments. The fix makes the option tri-state internally: - true: always include tarball URLs - false: never include tarball URLs - undefined (not set): use the existing heuristic that includes tarball URLs only for packages with non-standard registry URLs close #6667
zkochan
pushed a commit
that referenced
this pull request
Mar 7, 2026
…ndard URLs (#10621) When lockfile-include-tarball-url is explicitly set to false, tarball URLs are now always excluded from the lockfile. Previously, packages hosted under non-standard tarball URLs would still have their tarball field written to the lockfile even when the setting was false, causing flaky and inconsistent behavior across environments. The fix makes the option tri-state internally: - true: always include tarball URLs - false: never include tarball URLs - undefined (not set): use the existing heuristic that includes tarball URLs only for packages with non-standard registry URLs close #6667
2 tasks
This was referenced Mar 9, 2026
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #6667
Problem
When
lockfile-include-tarball-urlis set tofalse(the default), packages hosted under non-standard tarball URLs still have theirtarballfield written topnpm-lock.yaml. This causes flaky behavior -- the lockfile can differ between environments depending on registry responses, URL encoding, and redirect behavior.This has been a long-standing pain point especially for teams using private registries or npm Enterprise, where the inconsistent tarball URLs cause merge conflicts, CI failures, and general confusion.
Fix
The
lockfileIncludeTarballUrloption was effectively binary (true= always include, everything else = heuristic), so setting it tofalsehad no way to override the "non-standard URL" heuristic.I made it tri-state internally:
true: always include tarball URLs (unchanged)false: never include tarball URLs (this is the fix)undefined(not explicitly set): use the existing heuristic that includes tarball URLs only for packages with non-standard registry URLs (unchanged default behavior)This is done by:
falsedefault forlockfileIncludeTarballUrlinextendInstallOptions, so when the user hasn't set it, it'sundefinedlockfileIncludeTarballUrl === falsecheck intoLockfileResolutionthat skips the non-standard URL heuristicTest plan
falsefalseundefined)