Make the lock file more merge-friendly
See original GitHub issue- I have searched the issues of this repo and believe that this is not a duplicate.
Issue
When two devs install dependencies on separate branches, it is very easy to end up merge-conflicted, in particular, the metadata.content-hash
key often changes. It is very unclear how to resolve this manually, so I often delete the lockfile (or perhaps just that key) and rebuild it and, basically, hope that it comes out the same.
It seems like in some scenarios that merge conflicts could be resolved automatically based on pyproject.toml
. Yarn does this, for instance.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:48
- Comments:60 (24 by maintainers)
Top Results From Across the Web
In Makefile, how to cleanup lockfile files? - Stack Overflow
I would do the lock/unlock in the same target as file-maker : file.out: file.in lockfile $@.lock file-maker < $< > $@; \ status=$$?;...
Read more >File Locking - GitLab Docs
The first thing to do before using File Locking is to tell Git LFS which kind of files are lockable. The following command...
Read more >What is package lock json? Lockfiles for yarn & npm ... - Snyk
In this article we will discuss both npm's package lock file package-lock.json as well as Yarn's yarn.lock. Package lock files serve as a ......
Read more >Locking dependency versions - Gradle User Manual
Dependency locking makes sense only with dynamic versions. It will have no impact on ... See the description on updating lock files for...
Read more >Lock File | Developer Experience Knowledge Base
Many people decide to ignore the lock files and they do not commit it to Git. ... The package managers need more than...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
My 2 cents, if the
content-hash
format can be structured as a list of sorted main dependency names and hashes calculated from resolved sub-dependencies, then it would reduce merge conflict chance a lot. LikeI think this is still a valid issue and should not be closed.