-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Generate text lockfile along with binary lockfile (bun.lockb) and add "bun.lockb" to .gitignore #5486
Comments
For now, see the documentation on how to view lockfile diffs in Git: https://bun.sh/docs/install/lockfile The main (and only?) benefit of the binary lockfile is performance, and having textual lockfiles as the source of truth requires Bun to quickly determine whether the two are in sync. This could be done by comparing file timestamps, Make-style. Binary lockfiles will definitely be a headache when viewing pull requests in browsers. Even when using text lockfiles, I think merge conflicts should always be resolved with the package manager, not Git's auto-merge. |
Viewing binary lockfile diffs as text is helpful. But, it is not going to solve the problem that I mentioned i.e. how to deal with merge conflict in
NPM does not check whether
Merge conflicts is always a headache whether it is in binary lockfile (like By having both text lockfile and binary lockfile, developer can fix merge conflict in text lockfile and generate a new binary lockfile from the text lockfile. |
It's actually pretty good with Yarn, add long as package.json conflicts are fixed, just running yarn again automatically fixes merge conflicts in the yarn.lock |
@satya164 |
@sudo-barun I brought up Yarn because you are comparing with npm's lockfile format. The point is that the package manager could handle the lockfile conflicts automatically as Yarn does and it's not always a headache. |
@satya164 And, if this auto merge fixing feature really exists in Yarn, it would great to have such feature in Bun or NPM as well. |
If you have other syntax errors in yarn.lock then yarn will fail, so it's explicitly handling merge conflict scenario. You can find many references to automerge feature in this page: https://yarnpkg.com/advanced/error-codes#yn0046---automerge_failed_to_parse |
@satya164 |
realized there's an existing issue already, and I can agree, they're not very great to work with. being able to inspect and diff lockfiles easily is a very important functionality of lockfiles, it gives you the insight to know that your package manager is doing things right, and Bun's binary lockfiles just stands against all that. I'd like to go more but it's really just going to be a dupe of what I've said in #6276 (comment) ideally I'd prefer having an option to make use of text lockfiles entirely and NOT generate binary lockfiles at all, why keep two lockfiles with one of them ignored by Git? makes no sense, it'd be better to only have one source of truth |
We are unlikely to change Bun to generate two lockfiles, but we definitely know that not seeing If you use our VSCode extension, it will automatically show you the yarn-compatible output of the We haven't decided on anything right now, just sharing some thoughts. |
For what it's worth, I just ran into this exact issue with a merge conflict in my bun.lockb file. Like @satya164 mentioned, I'm used to Yarn, where I can easily run |
Just had the same though here... although We've all used text for comparison, I'm kinda open to experiment with the fact that human-related changes are specified at the |
So the diff approach has failed spectacularly for me. After upgrading to bun
I suspect bun changed the format of the lockfile and is not BC. Now I can't easily diff and investigate what lib version upgrades broke my app. If we can't rely on BC, then it'll be a major pain to work with git whenever the binary format changes. |
@Thinkscape bun's lockfile is always forwards compatible, but not always backwards compatible are you unable to view the lockfile when using bun v1.0.22? or is an earlier version of bun reading the lockfile? |
There are ways to view the contents of the file. That's not the point. The point is, there is nothing you can do if you have lockfile conflicts. You have to either generate a new lockfile (which is, as mentioned before, disastrous and makes lockfile useless in the first place), or accept one of the conflicted branches (and lock versions from other branch with next install, which can be disastrous as well). The suggested solutions (either changing the format to a textfile or generating two lockfiles - one for version control and the binary one for speed) would solve the issue it seems. I'm fine with any other solution to be honest, as long as I can use version control with lockfile. |
Just my personal opinion, but any performance improvements from a binary lockfile aren't worth the trouble of dealing with one. I'd rather have text diffs and easy conflict resolution. |
It was an upgrade from 1.0.1* (with lockfile generated by that one), to 1.0.22 (which generated a new one that I staged). I got around it by diffing manually, so it seems that the bug is somewhere in the bun vscode extension, or its interaction with newer bun, or something in between 🤔 |
After the incident around xz and checking in binary files in source code, I hope we can reconsider the whole binary lockfiles thing 🙂 Binary files should be considered untrustworthy and should not be checked into source code, especially binary files that we don't author ourselves (we don't generate lockfiles, package managers does that for us.) Bun is even more peculiar as it's the one lockfile format that allows being executed given the presence of a shebang on the start of the lockfile. Sure, it's just a shebang that tells the shell to open the file with Additionally, we should not have to be reliant on a GitHub bot to show us a diff during pull requests. GitHub is not the only place where source code development happens, and having to set up a CI for something that should be trivial seems like a waste of compute and electricity. |
I am now running in to conflicts all the time & the only practical resolution is to trash the lock file and reinstall, which somewhat defeats the point. Unless I'm misunderstanding something, the current situation is very fast but breaks the overwhelmingly most common version control workflows on the planet. |
The more I spend time with this, the more convinced I am that there is no justification for having a binary lockfile at all. Many orders of magnitude more time gets spent trying to work around the decision of having a binary lockfile (resolving conflicts, coming up with clever ways to show diffs in some tools, etc.) than is saved during install by using a binary lockfile instead of a text based one. I love the general obsession with performance in this project, but this ain't it Chief. Edit: To turn this rant into a workable suggestion, allow setting a text based lockfile format in bunfig.toml in a way that only that format gets used, as the single source of truth. |
I haven't research further, git can be configured to use different diff tool for certain extension, and but this also adds extra deps https://stackoverflow.com/questions/34885397/using-custom-diff-tool-with-git-show
|
We are planning to replace bun.lockb in a couple months. Tracking in #11863 |
This is following the Bun [guide][1]/[docs][2] for enabling git diffs for `bun.lockb` This won't work on GitHub, and this file isn't currently checked into git. It is supported by Renovate, so we could check it in, but there are various issues with this including [increased merge conflicts with dependency management][3] and [potential security threats][4]. This issue should be resolved and this change revertible when [Bun moves to a by-default text-based lockfile][5] and Renovate adds support [1]: https://bun.sh/guides/install/git-diff-bun-lockfile [2]: https://bun.sh/docs/install/lockfile#how-do-i-git-diff-bun-s-lockfile [3]: oven-sh/bun#5486 [4]: oven-sh/bun#5486 (comment) [5]: oven-sh/bun#11863
What is the problem this feature would solve?
Bun generates binary lockfile (
bun.lockb
) by default and is not added to.gitignore
file. This meansbun.lockb
mostly gets added to git repository (for example, https://github.com/elysiajs/elysia hasbun.lockb
).The problem arises when merging branches that have changes in
bun.lockb
file. Since,bun.lockb
file cannot be inspected, developer will most likely remove thebun.lockb
file and generate a new one. This can be disastrous as the new locked version of a package is different from the previous one.What is the feature you are proposing to solve the problem?
bun.lockb
to.gitignore
file by default to prevent merge conflict. Developer can force addbun.lockb
to git repo if needed.What alternatives have you considered?
No response
The text was updated successfully, but these errors were encountered: