Ask anything to Yarn Team

Yarn is a package manager for your code. It allows you to use and share code with other developers from around the world. Yarn does this quickly, securely, and reliably so you don’t ever have to worry.

Hosted by:

Comments (60)

Vincent Voyer's photo

What are your relations with the npm team? How did they react?

Michael Gilley's photo

Yarn is great and speeds up npm install times drastically! However, within the first few hours of the official release yarn issues came pouring in to the tune of >380 today. What is the yarn team doing to address those issues quickly? Is there any timeline for releases?

Also, has there been any discussion around adding yarn's caching functionality or parallel install into npm core? What do you see as the future of yarn and npm? Thank you!

Konstantin Raev's photo
  1. We hope the community will help out with the bug fixes. The code is quite easy to follow and improve.

  2. We target to make a branch cut / release every 2 weeks

  3. If Yarn can inspire npm CLI then it is a win for the community.

Vincent Voyer's photo

Ultimately we (developers) don't want to have to handle two package managers, how do you see the future of yarn versus npm? Do you have a plan?

Konstantin Raev's photo

We saw a problem - we solved it, we iterate on improving it. Same thing about all the other libraries/projects/platforms in the JS ecosystem.

Mev-Rael's photo

Why cat?

Sebastian McKenzie's photo

Software Engineer at Facebook

The name started off as KPM (Kittens Package Manager), and we had the original logo with the cat to signify that. My username on GitHub as kittens so it was kind of funny, it was always meant to be a temporary name since it's really close to npm and we'd prefer to distance ourselves from it.

We chose the name Yarn because it's short, has some relation to package management (knitting yarn is used as the foundation for textiles, Yarn is used as the foundation to hold all your dependencies together).

We kept the cat since it's cute and it's still related to Yarn since it's something common (stereotypical) that cats play with.

Ben Buchanan (200ok)'s photo

Why build a new system rather than push for changes in npm itself? There's plenty of speculation out there, but perhaps you could talk about how Yarn got started; or generally how that kind of decision plays out at facebook? (that is - ramping up an open source project of this scope and potential scale is not a trivial undertaking, how did you decide it was the right way forward?)

Christoph Pojer's photo

We did a JavaScript Air episode about this today and were asked the same question. I recommend watching the video:

George Kiknadze's photo

Why should I use Yarn instead of NPM?

Christoph Pojer's photo

The main selling point on smaller projects is that Yarn is much faster than npm. For larger projects we outlined why we built Yarn here:

A lot of other things like added security and determinism aren't something people think about every day but because Yarn uses a lockfile and installs are reproducible, you'll never run into "works on my machine" problems again. Every install of a project will produce the same dependencies.

Williams Isaac's photo

The fact that Yarn is built by brilliant heads from giant companies is enough to make us look into it, but how does yarn tackle security issues while loading dependencies. "npm allows scripts to run while installing dependencies".How does Yarn Solve that ?

Ygor Lazaro's photo


First of all, congratulations, team. Yarn's performance boost alone worths everything.

But before starting develop yarn, did you talk with npm's team about opensourcing/work with the npm and inprove it?

Konstantin Raev's photo

(my personal opinion) Reviewing large Open Source pull requests is very hard because you have to preserve backwards compatibility and make sure you don't break the world.

For a project like npm CLI the cost of changes is high and it would take us too long to communicate to get the ideas and code landed into the project.

We had our goals - performance, determinism and security considerations and the most efficient way would be to write a new tool from scratch.

Jon's photo

Inspired by the question from @kiknag ... Who should not use Yarn because of the difference between Yarn and npm?

Konstantin Raev's photo

Everyone should use Yarn

Michael Bates's photo

Why is Yarn called Micro Secure?

contra's photo

Congratulations on raising your $10MM seed round! What are you doing with that money?

Konstantin Raev's photo

Thanks but you probably confused us with some other company. Yarn is an open source project, not a startup

Chris's photo

Where did the name 'Yarn' come from?

Christoph Pojer's photo

Yarn is used for knitting: you use threads and knit them into something useful. Yarn is doing that for your project.

Jordan's photo

Is yarn a temporary solution to a problem (flattened packages, lock files) or do you see it as the next package manager?

I ask because we don't want to put energy into yarn if it's just keeping the seat warm for npm to take the attention back.

Show all replies
Christoph Pojer's photo

We think it is really important to stay compatible with the entire JS ecosystem and there is little value in changing how dependencies are stored in package.json. However, we add additional things in other files, like the yarn.lock lockfile. That way your project will stay compatible with npm but when you use Yarn you get additional guarantees like installing known versions of packages that will work well with your project.

It is unlikely that the structure of node_modules will change fundamentally because it'll have to stay compatible with node.js. It is entirely possible that the node module resolution algorithm may change one day, but that would affect npm and Yarn both the same.

Luke Jackson's photo

What influenced add over install it was the biggest barrier to switchover for me.. my muscle memory always goes for npm i package -D

Christoph Pojer's photo

We realized that npm install is actually doing two different things:

  • Install dependencies from package.json
  • Add new dependencies to your project.

If you forget to --save a dependency, you even end up with something in your project that isn't actually part of your package.json.

Since Yarn was a completely new project we decided to rethink this approach and be more sensible. With Yarn:

  • yarn install will install your dependencies based on the lockfile or write a lockfile if none exists.
  • yarn add <package> will add a new dependency and add it to the lockfile and package.json file.

We do not support installing packages that won't be part of your manifest file.

Jon's photo

If npm adds version locks in the future, would you consider Yarn less useful? Or you want it be different from npm?

Konstantin Raev's photo

Npm has version locks via npm-shrinkwrap.json. We will be happy if Yarn inspires npm CLI, some competition is always good

David Alexander's photo

It seems yarn is more focused on project sandboxing like bundler or virtualenv versus package management like rubygems or pip. This is made evident by design around yarn global * and lack of the same configurability currently present in the rival npm client.

Is this inferred roadmap intentional? What are your thoughts on focusing upon the sandboxing problem versus an overall better client for

Christoph Pojer's photo

We were scrambling a little bit to get ready for the open source release and the global command didn't get as much attention as we would have liked to give it. If you want to help contribute making it better, please open RFCs or send a pull request :)


Joshua Spac's photo

I’ve read that YARN caches copies of packages for offline installs, can you give a brief on how YARN does this under the hood?

Konstantin Raev's photo

I am planning to release a blog post at about the offline mode. Next week hopefully.

Justine's photo

Yehuda Katz had written a wonderful article on why he chose to start work on YARN. When did he first approach you, or did you approach him? While you’re at it, can we know the exact history of YARN?

Christoph Pojer's photo

I think Sebastian is way better equipped to answer this. However, we discussed this together with Yehuda on JavaScript Air ( ) so I recommend checking that out until he gets back to you.

Anwesh Mishra's photo

why the name yarn as there is already a yarn job scheduler which is an important part of hadoop.

Christoph Pojer's photo

Since both of the projects are solving fundamentally different problems, using different languages, we thought it was ok to name the project Yarn. I also answered above why we chose this name in the first place. When people talk about the hadoop project I heard most of them call it "Apache Yarn" which I think is enough of a distinction.

Raghunandan Gupta's photo

I have been coding JS for a long time now. Worked with a fee framworks too. When i code in react eco system i feel i write hardly 20% of my code rest all i just consume from NPM o YARN libraries. I hardly know my system's basic! Should that worry me?

Konstantin Raev's photo

No, that is what all of us do

Suarez's photo

Does YARN have any effect on how it handles node module registries?

Show all replies
Suarez's photo

Hey, Christoph! What's meant by my question is does Yarn have any functional differences from npm on how it downloads from node package registries?

Are there any specific changes that I have to keep in mind, or any changes that would benefit me so if I am maintaining my own registry; I can do it a little differently to optimize for YARN?

I hope I've not been too vague with my question. Thanks for your time. :)

Suarez's photo

What OS & browser do you guys use at Facebook for day-to-day development works?

Konstantin Raev's photo

All the people in my team have an apple logo on their computers. FB engineers have some flexibility to what tools and devices they need to perform.

Joshua Spac's photo

Why do the Windows version of YARN doesn’t come with emojis? No ❤ for Windows, eh?

Konstantin Raev's photo

Afaik there is no native support for emojis in Windows terminal

Nandan N's photo

As opposed to NPM’s nested dependency model YARN has a flat dependency model. Does this mean there is not a single case where there would be a duplication in the packages, right? Is this always a good thing to have?

Konstantin Raev's photo

Yarn follows the same model as npm@3. It tries to flatten packages if there are no conflicts, in that case it makes them nested. There is an option to force flat node_modules in Yarn, then you would have to resolve package conflicts manually.

Regina Hines's photo

What does YARN’s roadmap look like?

Christoph Pojer's photo

We are currently working on that. The open source launch has been quite overwhelming and we are still just catching up :)

Juanita Sutton's photo

Who chose the name YARN, why; and as someone has asked it already, why did you choose the Cat as an emblem?

What is the story on using a whole lot of emojis in the CLI? 😹

Christoph Pojer's photo

Thanks! I already answered why we chose Yarn in another question.

Robert's photo

I've read the advice to put yarn.lock under version control; for it helps to maintain the same structure of node_modules for every system. npm has shrinkwrap, how would you say is it different from yarn.lock?

Konstantin Raev's photo

yarn.lock is your source of truth, better keep it in version control to get reproducible builds.

We decided not to follow shrinkwrap json format because it is hard to read and review.

There are a few differences how it stores deep trees and that yarn.lock entries are sorted thus making git conflicts less common