Transcript from the "Yarn" Lesson
>> Brian: First thing, I need you to be on Node. If you're above 4, then you're golden. I actually installed Node 7 yesterday, so it'll be Node 7. But you can be on Node 6, anything above 4, and you're good to go. You could even be an io.js. It would still work just fine.
[00:00:14] So we're not gonna be doing anything too crazy with Node today. It just definitely has to be above 0.10. If you're on .10, you're gonna have a bad time. If you're on .12, you're gonna have a partially bad time. So just be above 4.
>> Brian: I use nvm.
[00:00:32] I strongly recommend it. You do not have to, but I found it to be a very useful tool.
>> Brian: And I think that they have fixed using Homebrew for installation. But I have historically had problems with installing Node via Homebrew. So if you did and you have permission problems, that's likely the reason.
>> Brian: Cool, so yeah, I think I'm on 7.0.0 today for Node.
>> Brian: Okay, we're gonna use Yarn today, because it's new and shiny and fun. [LAUGH] And that's kind of the point of these workshops, is to use new and shiny and fun things. So let's talk about what Yarn is.
[00:01:15] Yarn came out maybe, I dunno, a couple months ago, a month ago. And it kind of replaces npm for doing installs. But let's actually dive a little bit into that. So typically you would've been used to seeing npm install --save react, right? Like that looks familiar if you're a Node developer.
[00:01:36] That's just saying pull this off the npm registry, install it on my computer. Or install it particularly into this project, and then save that to my package.json. That's what that command does, right? So, instead of that, you're going to run yarn add react. And that's gonna do the same sort of thing.
[00:01:52] But the big difference is, is if you actually go into our project here, so let's open our project.
>> Speaker 2: I have a question. And I'm not sure how it fits in, so I'm just gonna ask it.
>> Brian: Sure.
>> Speaker 2: Richard is asking, can we use import and still do server-side rendering?
>> Brian: The answer is yes, and we will get there late tomorrow. But good question.
>> Brian: Okay, so we have our package.json here, which came with the start branch. So typically we would be doing all these dependencies individually. I just did them all for you. Because there's a lot of them and that would be a lot of installation.
[00:02:40] So typically you would come in here and say, npm install, and get all the dependencies installed for you. Instead we are gonna use yarn. And what yarn does that's peculiar as compared to npm is npm installs are not deterministic. Which is just a really fancy computer science term that just means that you can't run it from any state and end up in the same state, right?
[00:03:04] So if I install partially some of these dependencies and then go back later and install some different ones, and then I do it a different way again, I'm not gonna end up with the same node modules directly. It's gonna install them in different structures. It's going to be different every single time that I run it.
[00:03:22] Which, if anyone has ever dealt with non-determinism in their app, that's just a non-start. Like it's a really, really bad thing to not be able to reliably do the same thing every single time, right? So the smart people over at Facebook said this is a problem. We need to fix this, right?
[00:03:40] So they came up with this Yarn library that you can install these dependencies in any order, at any time, in any way, shape, or form. And you always end up with the same structure in the same way. And that's the core value proposition of Yarn, is that it's deterministic, it's faster.
[00:04:00] Typically npm installs for a big project like the Netflix project takes like two minutes to get through all of its dependencies to install. Yarn does it in like 10 seconds, 12 seconds. And then if you get it cached, it's even faster than that. So Yarn is fantastic for building apps.
[00:04:19] So if you have a Node project or anything that has a package.json for an app, I highly suggest using Yarn today. It's stable, it's good, it's really, really cool. Where Yarn kinda falls apart, because it has this locked down dependency tree, is building libraries. Cuz you want libraries to be a little bit fuzzier with which packages they pull in.
[00:04:44] The reason being is if I have a person that's pulling in my library. And they have one version of Lodash, and I'm using a different version of Lodash. And you don't want to have to include two different Lodashs if you don't have to. So that kind of fuzzy version matching that you get from npm is a little bit better to work with.
[00:05:03] So I suggest using Yarn for apps, not necessarily for libraries. What I was gonna show you is this yarn.lock file, which is what Yarn generates. And you can see here, [LAUGH] look how huge this is. This is all the dependencies for our particular project.
>> Speaker 2: So, I mean, maybe you don't know the Rails ecosystem, but this is like Bundler, basically?
[00:05:26] Yarn is like Bundler?
>> Brian: I think that's an apt comparison. But not knowing enough about-
>> Speaker 2: Right, yeah, I'm sorry.
>> Brian: But yeah, I think that sounds about right to me. I know when they built Yarn they brought in Yehuda Katz, who did Cargo for Rust. I think he also worked on Bundler.
[00:05:43] But he's definitely the Rails guy, right, or one of the Rails people.
>> Speaker 2: Yeah.
>> Brian: And he was one of the chief architects of how this works. So, yes, Yarn is awesome. I definitely suggest it.
>> Brian: So, yeah?
>> Speaker 2: Alexander asked a question. What is the stack used at Netflix database backend and frontend?
>> Brian: That is a wildly complex question to answer.
>> Speaker 2: I would imagine, yeah.
>> Brian: But to give you the too long, didn't read, version of it, I work on the Node part, which is kind of the aggregation layer. And that's written in Restify, Node, we use React.
>> Brian: Yeah, Restify is probably the most interesting part.
[00:06:27] And then we have a microservice architecture that we just pull in from different services. And those, for the most part, are written in JVM languages. And then they have their own databases, each one of them, so.
>> Speaker 2: Just a question on the yarn.lock file. How does that differ from like an npm shrinkwrap?
>> Brian: Yeah, so shrinkwrap kind of aims to address the same problem. If you've ever had to deal with committing and modifying shrinkwrap, it's problematic, to say the least.
>> Speaker 2: Yeah.
>> Brian: And the Yarn file is much easier. I've never had to modify a Yarn file by hand. And I definitely have had to modify shrinkwrap by hand.
>> Brian: I guess my answer to that question is, I'm not sure the internals of why they're different. But I will tell you that I find Yarn works a lot better.
>> Speaker 2: If you were to do a yarn add lodash, and Lodash hadn't previously been there, does Yarn know to update the lock file?
>> Brian: Yes.
>> Speaker 2: I've run into issues with shrinkwrap and, it's frustrating.
>> Brian: Yeah, no, the yarn.lock file, you don't have to do anything for it. There's no special commands for it. It's automatically just kept up to date every time you do a yarn blah. Like yarn remove, yarn add automatically updates yarn.lock.
>> Speaker 2: Thank you.
>> Brian: Yep,