Repository navigation
install: reuse the package of a file: folder that several packages declare #42545
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
Changes from all commits
3bd0761
ea56b34
16d69d8
8c84402
12dfa90
f34bf7d
26c3833
0656c69
d5346cc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2925,13 +2925,27 @@ fn get_or_put_resolved_package( | |
| ); | ||
| } | ||
|
|
||
| let path_is_top_level_relative = | ||
| this.lockfile.is_trusted_folder_dependency(dependency_id); | ||
|
|
||
| // transitive folder dependencies do not have their dependencies resolved | ||
| if crate::bin::bin_target_escapes_package_dir(this.lockfile.str(&folder)) | ||
| && !this.lockfile.is_trusted_folder_dependency(dependency_id) | ||
| && !path_is_top_level_relative | ||
| { | ||
| break 'res FolderResolutionValue::Err(crate::Error::MissingPackageJSON); | ||
| } | ||
|
|
||
| // One such path is one folder, so reuse the package another declarer loaded | ||
| if path_is_top_level_relative { | ||
| if let Some(existing_id) = this.lockfile.get_package_id( | ||
| name_hash, | ||
| None, | ||
| &Resolution::init(ResolutionTagged::Folder(folder)), | ||
| ) { | ||
| break 'res FolderResolutionValue::PackageId(existing_id); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🔴 Fresh hoisted installs now run a shared trusted Why this was flaggedTrigger: hoisted linker, no bun.lock yet, root declares Verification: The PR description's "Downsides" section states "a fresh install runs it at every tree position"; both halves of that note hold. At PackageManagerEnqueue.rs:2939-2945 |
||
| } | ||
| } | ||
|
|
||
| let mut package = Package::default(); | ||
|
|
||
| { | ||
|
|
@@ -2962,7 +2976,6 @@ fn get_or_put_resolved_package( | |
| builder.clamp(); | ||
| } | ||
|
|
||
| // these are always new | ||
| package = this.lockfile.append_package(&package).unwrap_or_oom(); | ||
|
|
||
| break 'res FolderResolutionValue::NewPackageId(package.meta.id); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟣 pre-existing, not blocking: Pre-existing, partial fix: users whose root
overridessupplies afile:folder through a scoped or ranged rule ("foo": {"x": "file:./vendor/x"},"x@^1": "file:...") still get one stub per registry declarer, so the isolated linker's EEXIST race the PR fixes for flat rules remains. The reuse at PackageManagerEnqueue.rs:2939 is gated onis_trusted_folder_dependency, whose override branch iscontains_name(OverrideMap.rs:291), which only consults the flat map. Fix: dedupe every override-supplied folder edge (the path is root-authored and top-level relative whichever rule shape produced it), e.g. gate the lookup onhas_rule_for_nameor on the edge having been replaced by an override, while keeping the escape check's narrower trust predicate.A small fix can ride a push you are already making; otherwise a short reply is enough.
Why this was flagged
A root package.json has
overrides: { "foo": { "x": "file:./vendor/x" }, "bar": { "x": "file:./vendor/x" } }and depends on registry packagesfooandbar, each declaringx; install runs with--linker=isolated. OverrideMap.rs:551 makes such rules scoped (is_flatfalse), sooverrides.getat PackageManagerEnqueue.rs:836 replaces eachxedge with the Folder version./vendor/x. In the Folder arm,is_workspace_dependencyis false andis_trusted_folder_dependency(lockfile.rs:898) returns false: the parent is an npm package andcontains_name(OverrideMap.rs:291-303) checks onlyself.map, neverscoped. Sopath_is_top_level_relativeat PackageManagerEnqueue.rs:2928 is false, the lookup at :2939 is skipped, and :2979 appends a stub per declarer, exactly as the base does. The isolated linker then runs one task per package id (Installer.rs:897-934), and both hardlink into the same store keyx@ file+.+vendor+x(Store.rs:412-418), reproducing theEEXIST ... failed to link packagefailure the PR describes for flat rules.Verification: pre-existing (the base already produces one stub per declarer on this path; the PR fixes the flat-rule path only). OverrideMap.rs:291-302
contains_nameonly consultsself.map, so PackageManagerEnqueue.rs:2928-2929 setspath_is_top_level_relativefalse for scoped rules and execution falls through toappend_packageat line 2979. The PR's new test uses only a flat rule.