feat(bun): support bun.lock
#9783
Open
Conversation
This file contains 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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
chris-olszewski
force-pushed
the
chrisolszewski/turbo-4268-warning-when-using-text-based-bun-lockfile
branch
from
7400701 to
f50149a
Compare
|
This is a great step toward support |
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.
Description
Closes #9628
Switch over from our usage of
yarn.lockand directly supportbun.lockparsing.We use
biometo strip out the trailing commas that appear in theworkspacesandpackagesobjects to leverageserdewhich I am more competent in. We can switch tobiomein the future and avoid a second pass, but I do not know how to do correct deserialization logic forPackageEntry(seede.rsfor examples of what this looks like) inbiome.I will call out is the fact that the lockfile keys in
bun.lockinclude too much information so we use resolved package identifiers instead e.g.package@(protocol:)?version. The keys can shift when the underlying package does not change resulting in incorrect behavior.A quick example to illustrate:
adepends on[email protected]bdepends on[email protected][email protected]will get they key ofsharedsinceais beforeb[email protected]will get a key ofb/sharedaupdates to[email protected], then thesharedkey will now point to[email protected]bsince it's key changed fromb/sharedtosharedand not rebuildasince it's key remainedsharedThis PR does not add support for
turbo prune.Reviewing each commit on it's own would probably be helpful.
Testing Instructions
Unit tests. Manual testing on a
create-turborepository.