Lerna Q&A

[00:00:00]
>> So the answer to your question about one package needing an older version of something well, we're seeing that right now with jest right? We downgrade a jest here to like the latest version is 20 653 And we're at 26 for we don't let ourselves float up to 26 five anything.

[00:00:21]
So that's what's giving us this local version of jest. Part of how JavaScript resolves dependencies. It allows for duplication. There are other types of package managers in other ecosystems that require you to They will they will scream at you and fail fail to work unless you have one set of one non duplicate dependency graph with exactly one version of everything you need that meets the needs of everything.

[00:00:54]
This would never work in JavaScript though, because we have so many little tiny packages. Alright, question in the class. So Jonathan asked, Does it make a big difference having something local versus at the top right having a local dependency in your node modules versus this outer node modules?

[00:01:12]
I would say zero difference its closest can be zero, like not a measurable difference. And therefore, you should optimize for other things. It is not faster to have something local Now the only way you'll end up with something local is if you have slightly different versions like we have to jests in this project right now.

[00:01:36]
That has some downsides, the size of this project on disk is going to get much bigger if we don't try to get on a mostly common set of things, and for that matter If you have two different jests, if there's an old bug and it gets fixed, like you could really confuse yourself by saying, Well I see this pattern.

[00:01:56]
It's working in one place. Why isn't it working in this other place? It's you can lose some significant productivity there. I would say that's the big risk of making more things local. Versus having this workspace route. With everything as much as possible your dev dependencies get hoisted up to that workspace level node modules folder, and because of the way require resolve works.

[00:02:23]
A node modules folder is a node modules folder when you say, give me just or give me lodash Like node is just going to go like look for local node modules and then go up to the parent look for node modules there go up to the parent, look for node modules there and it'll keep going up.

[00:02:41]
So all you'd be saving is just like a couple hops. And that would be measured in probably microseconds in terms of the time that it would take. Okay, so another question in the class was asked about symlinks. And the difference between these local, symlinks. Like, if I were to go back to having this dependency on types, and I would run your learn on link, This is an important topic and I wanna make sure we get it right here.

[00:03:17]
So like what, why do we need this local symlink if require resolve just works well. It kinda has to do with There are a couple reasons number one versions, right. So the same logic that I just applied to jest applies here as well. That's one reason. Another reason is tooling.

[00:03:40]
So typically, when you have like a build that watches for changes in certain places, Often you're gonna watch a folder and all sub folders. So if we had webpack running here and we wanted it to update any time we saved something, you can tell webpack to monitor node modules.

[00:04:05]
And if you're in there fiddling with dependencies, maybe you're trying to find a bug fix Right Webpack dev server will bounce, and you'll see the changes in front of you. That only works if you're in this node modules. And that's why the files that you're touching, being in your local node modules folder is a benefit to you.

[00:04:25]
That's that's another reason, right? So we can still watch everything that's going on here. And that lets you and we'll see we'll get to this workflow a little bit later. But you want to be able to basically fire up your workspace and then change anything anywhere, and your build reloads.

[00:04:46]
And it just you get the same benefit that you would if this were a monolith app. You have all of your code together and you can watch all that stuff. And I also see in the class, so, Jonathan from Eventbrite, they use bolt. So bolt is a package manager that is currently in preview.

[00:05:10]
It kind of does a lot of stuff that yarn does and yarn workspaces. It's still under active development looks really promising in terms of potentially being an alternative to learner. It's just not in a state where I would say those that are just learning mono repos. Would benefit from using it I'd say use lerna.

[00:05:31]
It's mature at this point. It has shortcomings. Both addresses some of these, but just go to the readme. See if it's ready by the time that you're watching this video. As of the time we're recording it is clearly stated as sort of like a a preview release.