Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the difference between yarn.lock and npm's shrinkwrap?

Recently I tried installing my Node packages with Yarn. It works great and it's a lot faster than NPM. Yarn automatically generates yarn.lock. We already have NPM shrinkwrap (npm-shrinkwrap.json).

Is there any difference between them? Does yarn.lock has any advantage over npm-shrinkwrap.json?

like image 531
Fizer Khan Avatar asked Oct 15 '16 09:10

Fizer Khan


People also ask

What is a yarn lock?

In short: When present in the project, yarn. lock is the main source of information about the current versions of dependencies in a project. Yarn uses that information to check if it needs to update anything – it compares dependency versions currently installed in a project (listed in yarn.

Is yarn lock same as package-lock?

In Yarn, it is called yarn. lock while in npm, it is called package-lock. json. As the name implies, this file locks the dependencies to their stipulated versions during the installation process, after establishing the versioning parameters in the package.

What is node shrinkwrap?

NPM shrinkwrap is used to lock the dependency version in a project. After installing packages using npm install or npm install package-name and updating your node_modules folder, you should run npm shrinkwrap. It will create new npm-shrinkwrap.

Does npm respect yarn lock?

The simple answer is: because yarn. lock doesn't fully address npm's needs, and relying on it exclusively would limit our ability to produce optimal package installs or add features in the future.


2 Answers

The yarn.lock file is quite similar to other package managers' lock files, especially Rust's Cargo package manager, which has Cargo.lock. The idea of these lock files is to represent a consistent set of packages that should always work.

npm stores dependency ranges in the package.json file, which means that when someone installs your package, they might get a different set of dependencies to you, since you might be running outdated packages (although they still satisfy the dependency range you specified). Take, for example, someone who has specified the dependency "foo": "^1.0.0". They might have actually installed foo v1.0.1, because that was the latest when they ran npm install, but later on, someone installs your package and gets the dependency foo v1.1.0. This might break something unexpectedly, which can be avoided if you have a yarn.lock file which guarantees consistent package resolution.

As for comparison with npm shrinkwrap, the documentation explains it very clearly:

It’s similar to npm’s npm-shrinkwrap.json, however it’s not lossy and it creates reproducible results.

The documentation also advises committing yarn.lock to your repositories, if you're not already doing this, so you can reap the benefits of consistent and reproducible package resolution. This question also explains further why you should do this.

The lossy behaviour of npm shrinkwrap is due to the non-deterministic algorithms used by npm itself; as stated in the comments of another answer, npm shrinkwrap > npm install > npm shrinkwrap is not guaranteed to produce the same output as just shrinkwrapping once, whereas Yarn explicitly uses "an install algorithm that is deterministic and reliable".

like image 86
Aurora0001 Avatar answered Sep 21 '22 13:09

Aurora0001


Is there any difference between them

Yarn follows a more deterministic algorithm, compared to npm shrinkwrap. If you're using Yarn, continuing to use shrinkwrap would be counter-intuitive

You can find this in the documentation for yarn.lock:

It’s similar to npm’s npm-shrinkwrap.json, however it’s not lossy and it creates reproducible results

However, the question still remains whether yarn is production ready. There are still a bunch of glaring bugs open on the GitHub repo, so I would wait it out for a month or so.

like image 39
nikjohn Avatar answered Sep 21 '22 13:09

nikjohn