Check .gitignore if both yarn.lock and package-lock.json exist.

[vivaxy]

If yarn.lock and package-lock.json both exist, it could be better if we can check:

1. If this is a git repository.
2. If one of the lock file is ignored.

If yarn.lock is ignored, we can assume that the project uses npm maybe.
If package-lock.json is ignored, we can assume that the project uses yarn maybe.

[kevincaradant]

Hi
I like this feature. In my case, we are a team and we use both of them.
However, my colleague doesn't use 'yarn'. So when she wants start the command, the lib want to execute it with yarn instead of npm :(
Thanks :)

[camacho]

This feels like a highly opinionated solution (which is ok) for a use case that I don't feel provides a clear signal about the user's intention (compared to having specific files present or package managers installed).

To elaborate, I can see potential situations where the lockfiles are ignored in a .gitignore for the package manager that is being used. With this proposed solution, we could end up choosing the wrong package manager in this case.

Is there a way to accommodate both cases?

[kevincaradant]

Hi

My original / first answser was not very clear, it's true ;)

@camacho , as I explained, it's already the case about => we could end up choosing the wrong package manager in this case.

Why choose absolutly yarn if you see a yarn.lock file in the project ? You see what I mean :)

Allowing to gitignore one of them, this allow for each user / developer to have locally his own config file directly from the gitignore file.
In company, like mine, you have "default settings" which is to use node with npm so we want to keep package.json in the project.
In the moment, I excluded yarn.lock adding it in the gitignore. Using this way, my colleague and me can run the project without any issue with your library. Even if I know, in this case, your lib will run it with 'npm'.
But if I want to run in local with yarn, it's my problem not yours in this case ^^.

HOWEVER, without the feature requested in this thread, I can't let the yarn.lock file in the project on github for example, so when I run yarn, I don't use the locked libraries if I don't already have the yarn.lock file locally ;)

Anyway, I hope that will be more clear. Even if, when I wrote this mesage, I was lost during few seconds :p

[camacho]

Thanks for the response! I better understand the case you are explaining. I am still hesitant because I see the strength of the signal from an ignore file being weaker than the signal from the "yarn.lock file in the project", as you wrote. I should take some time to think about it more. The idea is clever and addresses a use case I had not considered.