Always commit dependency lock files in general
As is covered elsewhere, dependency lock files, which are supported by many package management systems (e.g.:
composer and bundler), should be committed to the codebase in end-of-chain projects - so that each individual trying to run that project is doing so with exactly the tested set of dependencies.
It's less clear whether lock files should always be committed into packages that are intended to be included in other projects (where looser dependencies are desirable). However, both Yarn and NPM (as covered by @Cyrille) intelligently ignore yarn.lock and package-lock.json respectively where necessary, making it safe to always commit these lockfiles.
So you should always commit at least one of yarn.lock or package-lock.json depending on which package manager you're using.
Should you commit both yarn.lock and package-lock.json?
At present we have two different package management systems, which both install the same set of dependencies from package.json, but which generate and read from two different lockfiles. NPM 5 generates package-lock.json, whereas Yarn generates yarn.lock.
If you commit package-lock.json then you're building in support for people installing your dependencies with NPM 5. If you commit yarn.lock, you're building in support for people installing dependencies with Yarn.
Whether you choose to commit yarn.lock or package-lock.json or both depends on whether those developing on your project are only using Yarn or NPM 5 or both. If your project is open-source, the most community-friendly thing to do would probably be to commit both and have an automated process to ensure yarn.lock and package-lock.json always stay in sync.
Update: Yarn have now introduced an import command which will generate a yarn.lock file from a package-lock.json file. This could be useful for keeping the two files in sync. (Thanks @weakish)
This issues was discussed at length on the Yarn project in:
Both are now closed.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
