feat(turborepo-lockfiles): update bun.lock support to match Bun's current implementation #10729
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Someone is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
…rent implementation Updates Turborepo's bun.lock parser to support features from Bun's latest lockfile format, addressing compatibility gaps and adding missing functionality. ## What? - Add LockfileVersion enum for v0/v1 format handling - Fix global_change() to detect version changes (was only checking package manager) - Add support for new lockfile fields: trustedDependencies, overrides, catalog/catalogs - Implement platform-specific constraints (os/cpu fields) - Add v1 workspace optimizations (reduces redundant package entries) - Add bun_global_change() standalone function for API consistency ## Why? The existing implementation had several gaps: - Cache invalidation could fail when lockfile versions changed - New Bun lockfile fields were silently ignored - V1 optimizations were not implemented - Platform constraints were not parsed ## How? - Catalog resolution via resolve_catalog_version() method - Override support via apply_overrides() method - Negatable enum for platform constraints - Version-aware workspace resolution - Comprehensive subgraph filtering ## Testing Ran tests with: ```bash cargo test -p turborepo-lockfiles ``` - Added 43 new tests (72 total Bun tests, up from 29) - All 238 package manager tests pass - Test coverage includes: version detection, catalogs, overrides, v1 workspaces, platform constraints, integration scenarios ## Notes - Based on Bun's src/install/lockfile/bun.lock.zig - Follows existing patterns from npm/pnpm/yarn implementations - Some features (trusted deps, platform filtering) are parsed but not actively used 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
|
@Jarred-Sumner Any updates or timelines on this? Seems like turborepo with bun catalogs just triggers fan-out tasks whenever there is a change to the lock file (e.g. adding any package, local workspace or external). |
anthonyshew
changed the title
![vercel[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
| let workspace_key = format!("{workspace_name}/{name}"); | ||
| if let Some((_key, entry)) = self.package_entry(&workspace_key) { | ||
| // Check if the entry matches the override version (if different from resolved) |
There was a problem hiding this comment.
When an override is specified but the overridden package doesn't exist in the lockfile, the code silently ignores the override and returns the original package instead of failing or returning None.
View Details
📝 Patch Details
diff --git a/crates/turborepo-lockfiles/src/bun/mod.rs b/crates/turborepo-lockfiles/src/bun/mod.rs
index d78140d22..96a69e7b8 100644
--- a/crates/turborepo-lockfiles/src/bun/mod.rs
+++ b/crates/turborepo-lockfiles/src/bun/mod.rs
@@ -416,6 +416,10 @@ impl Lockfile for BunLockfile {
key: override_entry.ident.to_string(),
version: pkg_version,
}));
+ } else {
+ // Override specified but target package not found in lockfile
+ // Return None to be consistent with catalog resolution behavior
+ return Ok(None);
}
}
Analysis
Inconsistent error handling for unsatisfiable overrides in BunLockfile.resolve_package()
What fails: In crates/turborepo-lockfiles/src/bun/mod.rs, the resolve_package() method silently ignores overrides when the overridden package version doesn't exist in the lockfile, returning the original package instead of None.
How to reproduce:
,
"packages": {"foo": ["foo@1.0.0", {}, "sha512"]},
"overrides": {"foo": "2.0.0"} // 2.0.0 doesn't exist!
}));
let result = lockfile.resolve_package("", "foo", "^1.0.0").unwrap();
// Before fix: returns Some(Package{key: "foo@1.0.0", ...})
// After fix: returns NoneResult: The method returns Some(Package{key: "foo@1.0.0"}) instead of None, silently ignoring the override.
Expected: Should return Ok(None) to be consistent with catalog resolution behavior (lines 367-373), which returns Ok(None) when a catalog reference can't be resolved.
Fix: Added else clause after line 419 to return Ok(None) when override package not found, matching the behavior of catalog resolution and preventing silent fallback to the original package.
There was a problem hiding this comment.
I think we're far enough along on this to merge. We can put it in people's hands and see how it does on a canary.
Tremendous thanks to @Jarred-Sumner for kindling the flame to get us to do this, finally. Let's roll.
|
Not sure why the check for a site build is hanging. The site is done building successfully. I'll merge past it. |
|
@anthonyshew Thanks so much for this! Really appreciate your work! |
|
@Firgrep Appreciate the kind word. Please try it out and let us know how it goes, per this comment. |
4 participants
Description
Updates Turborepo's bun.lock parser to better align with Bun's current lockfile format implementation. This addresses version detection issues, adds support for new lockfile fields, and implements v1 optimizations.
Testing Instructions
Test Results
Background
While investigating Turborepo's bun.lock support against Bun's implementation (
src/install/lockfile/bun.lock.zig), I identified several gaps:global_change()only detected package manager changes, not lockfile version changesChanges
Core Fixes
Version Detection
LockfileVersionenum for v0/v1 handlingglobal_change()to detect version changes (prevents incorrect cache hits)bun_global_change()for API consistency with other package managersNew Field Support
Platform Constraints
Feature Implementations
resolve_catalog_version()methodapply_overrides()methodNegatabletype with serde supportResolution Order
The implementation follows this precedence: catalog → override → patch
Areas of Uncertainty
I want to be transparent about areas where I'm less confident or made assumptions:
V1 Behavior Beyond Workspaces: While I implemented the workspace optimization mentioned in Bun's source, there may be other v1-specific behaviors I'm not aware of.
Trusted Dependencies: I parse and filter these, but I'm unsure if Turborepo needs to actually use this information for any security/installation decisions.
Platform Constraint Application: The
Negatable::allows()method is implemented but unused. I'm not sure where in Turborepo's architecture platform filtering should actually occur.Catalog Precedence: I assumed catalogs should be resolved before overrides based on the code structure, but this precedence isn't explicitly documented.
Error Handling: Some edge cases (like circular workspace dependencies or conflicting overrides) may not be handled optimally.
Potential Issues
Performance: The catalog resolution adds an extra lookup step during package resolution. For large monorepos with many catalog references, this could impact performance.
Backward Compatibility: While I've maintained compatibility with existing lockfiles, the changes to
global_change()will cause cache invalidation for projects upgrading Turborepo.Incomplete Platform Support: The platform constraints are parsed but not actively used for filtering during dependency resolution.
Questions for Reviewers
UnsupportedVersionerror be recoverable or fatal?Known Limitations
Negatable::allows()method for platform matching is unused (added for completeness)Additional Context
This is a draft PR as I would appreciate feedback on the implementation approach, particularly in areas where I made assumptions about intended behavior.
🤖 Generated with Claude Code
Co-Authored-By: Claude noreply@anthropic.com