Skip to content
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

[Feature Request] git diff friendly format of lockfile #58

Open
SoonIter opened this issue Aug 7, 2023 · 0 comments
Open

[Feature Request] git diff friendly format of lockfile #58

SoonIter opened this issue Aug 7, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@SoonIter
Copy link

SoonIter commented Aug 7, 2023

The story of users

  1. yaml file is not friendly to git diff. Almost every time in git diff, each diff block will be confused by same content from different rows and different projects as shown in the images below. This kind of code diff is not easy to read.

  2. In a larger repository, there are usually many people working together, but their projects may be irrelevant. The lockfile conflict causes them to have to merge manually.

image

image

the solution I think

Inspired by Go's lockfile called "Go.sum", new format of lockfile stores the meta data of each packages in only one line.

image

The format I designed is like this.

before

image

after

// new-format.lock
// Nodes
[email protected] sha512-xxxxxxxxxx=  noDev
[email protected] sha-xxxxxxxxxx= hasBin noDev
[email protected] sha512-xxxxxxx= engines: {node: '>=0.10.0'} noDev

// Edges
[email protected] -> [email protected]
[email protected] -> [email protected]

Then, if I add a new version of loose-envify,code diff would become like this.

// new-format.lock
[email protected] sha512-xxxxxxxxxx=  noDev
- [email protected] sha-xxxxxxxxxx= hasBin noDev
+ [email protected] sha-xxxxxxxxxx= hasBin noDev
[email protected] sha512-xxxxxxx= engines: {node: '>=0.10.0'} noDev

- [email protected] -> [email protected]
- [email protected] -> [email protected]
+ [email protected] -> [email protected]
+ [email protected] -> [email protected]

The reason why I open this issue is that I think the new package manager should have more opportunities to try experimental features

@anonrig anonrig added the enhancement New feature or request label Aug 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants