Should I need to put yarn.lock in .gitignore?

[psaung]

No description provided.

[goenning]

You should add yarn.lock to your git, don't ignore it.

See https://yarnpkg.com/en/docs/migrating-from-npm

When you run either yarn or yarn add <package>, Yarn will generate a yarn.lock file within the root directory of your package. You don’t need to read or understand this file - just check it into source control. When other people start using Yarn instead of npm, the yarn.lock file will ensure that they get precisely the same dependencies as you have.

[donaldpipowitch]

Just to be clear - this also applies to libraries as well and not just applications, because opposite to npm-shrinkwrap.json only the yarn.lock of the top level project will be used, right? So dependencies of dependencies with yarn.lock files will not generate unnecessary duplicates. It is useful for libraries, if you have complex dev dependencies and you want every contributor of your library to have the same build and test configurations.

Is this correct?

[Pfeifenjoy]

@goenning
Maybe it is not always the best idea to put the yarn.lock file in your repository.
E.g. I am using sinopia. Therefore I have a custom npm registry. I use this registry mainly for other projects where I have private modules.
But when I push a public project to a git repository, which only has public dependencies, the yarn.lock has the wrong links to the dependencies and my CI system will fail to build the project.
The dependencies point to my local repository.
This can also happen to other developers if they clone my repository.
Is there any way to get around this except of putting the yarn.lock file into the gitignore?

[DovydasNavickas]

Also, if you have preauthenticated npm registry, e.g. myget which proxies to npm, yarn.lock will have preauthenticated links to packages, which is a major security breach 🎉
This should be documented somewhere with a big font.

[beenotung]

@Pfeifenjoy what if you link to private packages using git submodule instead of npm?
using git, you can access the repo using deploy key (via ssh)

[Pfeifenjoy]

@beenotung I am not a big fan of using git as a dependency manager, because it is very slow, does not resolve dependencies the way I want them to be resolved and in my opinion it is best to have every dependency in one manager.

Also the dependency I am referencing will all (not only my own projects) get a different address, because they are saved in my local sinopia account. It would be very tedious to reference all node modules which my projects depends on in git.
Furthermore it is just easier to remove the yarn.lock file.

[thisolivier]

@Pfeifenjoy Is there possibly a conflict in what you want yarn to do? If you want to provide a way to make sure other installations have your dependencies, include it- it's performing as intended. If you're pulling in private repos and sources, you ought to be very cautious about how you share your code per-say, in the same way that you specifically would ignore any keys or salts from a repo (if you want to see a warning on the project readme, I'd make a feature/pull request).

Possibly yarn should give a warning when run alerting a user that access to an authenticated source has been included in the lock file, but again, that would be a feature request.

[Pfeifenjoy]

@thisolivier sounds reasonable

[bennyschmidt]

I disagree with the most upvoted comment here:

• if the project uses npm, commit package-lock.json to the repo and gitignore yarn.lock
• if the project uses yarn, commit yarn.lock to the repo and gitignore package-lock.json

That is, you should not always commit yarn.lock to the repo, and to answer OP's question, yes you might want to add it to .gitignore.

When other people start using Yarn instead of npm, the yarn.lock file will ensure that they get precisely the same dependencies as you have

First off, no it won't - only if you're only ever using the public npm registry. Worse if you're not authed to your private org in yarn, (even if you still are in npm), and a package of the same name exists in the public registry, it'll just install the wrong one with no prompt. It would be confusing why your yarn is installing with no errors, yet the app doesn't work when using yarn yet it does when using npm.

Secondly, many codebases don't use yarn. It's not a matter of "when they switch over to yarn". Almost all my node services & basic web servers use npm with no plans to move to yarn. I do like yarn with React, that's about it.

As @Pfeifenjoy mentioned above:

I have a custom npm registry. I use this registry mainly for other projects where I have private modules

But when I push a public project to a git repository, which only has public dependencies, the yarn.lock has the wrong links to the dependencies and my CI system will fail to build the project.

^ Another thing, even when you solve it locally, you have to incorporate the solution into the yaml or whatever config for CI & anywhere else you spin up the app - some kind of logic that can tell when to use which registry and which command - sounds annoying and unnecessary

Another thing - if you encourage everyone to always commit yarn.lock to the repo and never ignore it, developers will start using yarn in a repo that already heavily relies on npm. Even in the cases where it works fine there will be redundancies in the 2 lock files, and it will open a door to dependency hell. And you know some developer will commit a ~25k line yarn.lock at some point messing up your contributions graph 😂

[AnshulNautiyal]

Hey Folks,
I created a FE project and install and add DEPENDENCY in package/yarn json files...It will generate yarn/package lock file automatically.
In the first commit, i committed the lock file with it so that other developers while installing dependency will have same order/version that i have installed in my system. No issues for module difference.
But when other devs install the dependency from package/yarn json files, It also generates yarn/package-lock file automatically.

yarn/package lock files should only be committed

1. when u add new dependency to package/yarn json so that all dev have same versions installed (make sense)
2. if developer is just installing dependency from package/yarn json files) (No new dependency )
3. both 1 & 2