Some of its commands, notably install, can modify yarn.lock if it's out of sync with package.json, and I think that by default they still do so silently. You ca

Some of its commands, notably install, can modify yarn.lock if it's out of sync with package.json, and I think that by default they still do so silently. You can override that modification with various options, but it seems to defeat the point of a tool whose main function is to ensure stable, repeatable builds if something on say your CI server or a developer's machine after a source control merge can wind up with a locally modified yarn.lock that doesn't fetch identical versions of all dependencies to what everyone else is using. Edit: Also thanks for the tip about npm's new locking mechanism. Apparently that arrived with NPM 5. I just checked, and we have developer machines here that were last updated well under a year ago and are still on NPM 3, and that had itself been installed along with something like the third new major version of Node in not much over a year. I don't know how anyone is supposed to do development intelligently while the most fundamental tools for things like dependency management are bumping a major version and radically changing how they do even the most basic and essential things literally every few months. :-(