Yarn 2 and Dependencies Q&A

[00:00:00]
>> We had some great questions in class that I kind of want to recap a little bit here. In case you're watching this course and you have the same questions. So the first one we got was about having the correct version of yarn and a node part of what we installed and we went through the readme and Follow the instructions there was, we set up volta.

[00:00:27]
So the point of volta is, it manages the versions of things in your tool chain. So if we did volta pin node and yarn you can see that we're getting you know, as of this moment This is the latest LTS node. There's also a maintenance LTS, which is node 10.

[00:00:52]
Node. 12 is also an LTS and then we've got yarn one dot 22. And this is all stored in your package JSON. So even if you're using, let's say, node 14, In other places on your machine, right? Let's say that you have that globally installed, you are kicking the tires at the latest stable release.

[00:01:11]
Well, if you use node from within the project, you are always good. I think maybe we have to leave and enter something. Let's try closing and reopening. Interesting, I kinda expected to get the right node here. Well, I should be getting node 12 We might be seeing a bug here, folks.

[00:01:46]
I don't think it'll hold us back but, Getting the correct yarn at least. I'm using node 1219. Am I though? I will get in touch with the volta team and make sure that this all works out. But the the point of this is, you should just have this in your package JSON and it should just work.

[00:02:17]
Clearly there's some funky stuff going on here. Again, I don't think we're sensitive to any particular node version, right now. At the time of recording this course, but this is more for those of you who are watching this a year from now, I want to make sure that everything works for you and that it will work by the time it matters.

[00:02:37]
So that's number one, node and yarn versions. The second question I got was, are we going to be talking about yarn V2 So, yarn v2 is a total reimagining of the way package management works. I liken the difference between yarn v1 and v2. It's kind of like the difference between Angular v1 and v2 in that, yep, you almost have to think of it as a completely different project.

[00:03:10]
It's not just a few changes, and that's get rid of some tech that it is. It's a different thing. I don't know of any big companies that currently use yarn v2. And this is because oftentimes a lot of tooling has to be built on top of yarn. We're going to use Lerna later today that's built on top of yarn.

[00:03:35]
So all of these things will have to change in non trivial ways in order to take advantage of yarn v2. So it's an interesting idea. It solves some problems. But it's gonna take a lot of work for the ecosystem to catch up and for that to become the norm.

[00:03:59]
Good questions. I have a follow up question and I'm allowed to, my question has to do with just like right now we are configuring just basically at the package level, is there merit to having it at the root level and essentially just pointing just to like for coverage and whatnot to like each package independently Good question from the class.

[00:04:23]
So, is there any difference to us stating that Jest is a workspace level dependency kind of how we treated Rim Wrath, right? Why are we putting Jest as a package level dependency. Dev dependency at that matter. And why is rim ref at the workspace level? Well, for one, one version of rim ref will do for me.

[00:04:51]
I just want to get rid of some files. I'm invoking it as a CLA So it may not seem the difference may not be apparent at the moment, but I want you to imagine this. What if we had this? What if I use a slightly different version of for one of my packages let's see what happens.

[00:05:19]
We'll look at that. So, the fact that we have a different version of jest for one package versus another, you can see that in my utils Package, I still just have only a. bin sub folder in its local node modules. But up here in types where I downgraded jest, right it was it was 26 ,5 now it's 24 and I'm not letting it float up to.

[00:05:49]
The latest version here. Now it gets its own local version of jest. And if you follow my advice and you go to the Node JS documentation and go look at the require resolve docks, the section that says all together, right, where it describes the algorithm Basically when you say, require jest, well, the first place you're gonna look is this local node modules.

[00:06:17]
And if you find something that resolves, you will never bubble up to this outer node modules. So this is the way that we can handle having different versions of dependencies. For various packages and it will happen, it will happen in an ideal world like it. One would hope it doesn't.

[00:06:39]
But just imagine. All you have to do is imagine an upgrade on a bunch of packages. That's just too big for one poll request. So if you have, imagine you have, you know, 30 packages in here, and you're upgrading to a major release of TypeScript, you're not going to want to try to do that in one shot, and just bump everything up together.

[00:07:03]
So you'll bump a few of them up. And then you'll be at this in between spot and then you'll finish your work, but for that in between time You're gonna have some of these like local versions. So that's why we allow some of these things to be dead dependencies on a pro package level where as other things they can operate at the work space level.

[00:07:26]
All it is, it's a platform in the platform way. To say RM dash RF, it's never going to be anything else. It's very, very stable in terms of an API surface. There's no one's gonna revolutionize what rm rf means, right? You just pass it some files to delete and you're done.

[00:07:47]
So, in that sense, I don't need each package to have its own version of of rim graph. Recorded that answer your question.>> It did thank you.
>> Fantastic. Very good question to have. And same with the Babel plugins. By the way, those are things that just inherently, some of them are gonna float forward and flow backward.

[00:08:10]
I might not need TypeScript in some places, I might have react in some places. So it's important to be able to, To have these little knobs that you can turn, and it matters most around upgrades.