Ensuring that Dependencies Work

[00:00:00]
>> So now it's time for us to make sure that these new packages that we just added to our project, they do the same things that we have benefitted from so far. And you can see Like, we've already talked about this stuff. So these are already set up with some of the things we've done so far.

[00:00:22]
They already know about scripting. Right? They already take responsibility for their own clean Now, let's check this one just to make sure everything is copacetic. Looks good. This one has different like an additional script which is totally fine for it to do this. Cuz in the case of this UI, it has some functionality that just doesn't apply to other things, right, starting up a local web server like that doesn't really make so much sense in the context of just type information.

[00:00:59]
But here, it's great. All right, let's see if Yarn build works. Building the workspace everything should have stuff in a dist folder. And in fact, we do. Now let's say let's try Yarn went starting with the types package, then utils, and then data. And then finally the UI.

[00:01:28]
We didn't make it past data looks like we have a problem here. What's the problem? I have a debugger somewhere. I should probably remove that. Good job linter Types he tells again going from the bottom up Success across the board. Now, if I wanted to make that run a little bit faster.

[00:02:02]
All that have to do is go like this. Let's see what happens. So I basically this is how many lanes I allow on the highway. When I only have one lane. The cars are ordered in a way that makes sense. lowest level first and then building up. Here, up to four things can happen at the same time.

[00:02:22]
But if this works the way I suspect it well, we're still going to have so it's like types in utils so I save this interesting, still seems pretty serial I know why it's serial This is a good opportunity for me to talk about this. So we introduced a fake dependency.

[00:02:55]
Right? We said that I depend on types utils depends on types. We don't have a need for this anymore. We have some real examples in our project now, so I can run yarn, I can learn a link I've removed that. So now like the way we had things before it was types utils data UI.

[00:03:15]
Now that we've removed that interdependency of the two lowest layer, two lowest layers, it's types in utils. Together, then data then UI. Let's see if it makes a difference. See that? See how they're interleaved, utils and types of going together first, and then data by itself, and then the ui by itself.

[00:03:37]
So we kind of sped our build up because there's no reason why you can't do those two things together. For lint errors, this might be okay. Given that interleaved output, I mean, for that kind of thing, I'm just kind of clicking on single lines. I don't really care where they are as I address this stuff.

[00:03:55]
Tests are a bit different cuz often you have a folder of tests and then Some assertions and if things get mixed up. Those lines of output don't really stand on their own. And as many things get interleaved, it can get really confusing linting I'm a little more tolerant of it.

[00:04:12]
But there you go, you're seeing that learner does a good job of figuring out the right order to do things and even though I allow up to 4 things to happen at the same time, Our dependency graph of our own packages doesn't really permit us to go up to four.

[00:04:29]
It's just not we don't like at most. We have two things on a particular layer and we build layer by layer by layer. Thank you start, hopefully you're starting to see some of the value that a tool like this adds to your project. And it's important to understand also that all the tools that are aiming to compete with lerna in this space, they tend to aim to do the same thing.

[00:04:57]
So if you're interested in the rush stack from Microsoft or bolt is an up and coming yarn like purely yarn based mono repo tool that is currently, in progress and an early preview. They could be a drop in replacement. I mean not in terms of the commands are exactly the same.

[00:05:20]
I guess that's what a drop in replacement would be. But they do equivalent work, right? They aim to make things like this easy because this at a large scale, large number of packages, this kind of stuff just gets to the point where even the most meticulous team will often make mistakes in managing this stuff the right way, building things in the right order.

[00:05:43]
Write so that you don't have like, This new package compiled but only with the stale out stale old build from this old thing so everything looks good but it's not really good. Like you don't want that you want to build in this order.