What are your relations with the npm team? How did they react?
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!
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?
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.
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?)
Why should I use Yarn instead of NPM?
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.
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 ?
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?
(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.
Inspired by the question from @kiknag ... Who should not use Yarn because of the difference between Yarn and npm?
Congratulations on raising your $10MM seed round! What are you doing with that money?
install it was the biggest barrier to switchover for me.. my muscle memory always goes for
npm i package -D
We realized that
npm install is actually doing two different things:
- Install dependencies from
- 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
Since Yarn was a completely new project we decided to rethink this approach and be more sensible. With Yarn:
yarn installwill 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
We do not support installing packages that won't be part of your manifest file.
Where did the name 'Yarn' come from?
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.
Isn't everything in JS community a temporary solution to a problem? Adopting Yarn is not that hard, it is still compatible with commonjs/node modules resolution
That answer leads well into my next question then....
Yarn is a drop in replacement today for npm's package.json. Is the ongoing strategy going to be keeping yarn and npm in sync with package.json structure?
In other words, if the next version of npm updates the structure of node_modules or package.json, will yarn still move to be compatible with it?
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.
why the name yarn as there is already a yarn job scheduler which is an important part of hadoop.
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.
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?
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 npmjs.org?
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 :)
If npm adds version locks in the future, would you consider Yarn less useful? Or you want it be different from npm?
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?
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?
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? 😹
Why do the Windows version of YARN doesn’t come with emojis? No ❤ for Windows, eh?
Does YARN have any effect on how it handles node module registries?
Hey! Would you mind clarifying your question? I'm not really sure what you mean.
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. :)
What does YARN’s roadmap look like?
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?
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?
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