Lerna Config & Versioning

[00:00:00]
>> By the way, if you feel like you're falling behind or there's something wrong with your project and you want to check out my code on the Git repo, there's this branch called f e. m. We're now on the fifth step and we are going to be adding a tool called learner to our mono repo project.

[00:00:30]
The learner solves a bunch of problems and we're gonna feel the benefits. Having solved one big problem almost immediately, and that is it provides us with a mechanism to run a command on each package in our mono repo with a one c li right. So if we wanted to just say Run all the tests.

[00:00:55]
learner makes that really easy. Now it does many other things. It's kind of like a Swiss Army knife for JavaScript and TypeScript mana repos. But that's that is the first benefit we're gonna feel. So learner is a workspace level dependency. We don't have a different version of learner we could not have a different version of learner for each package.

[00:01:20]
So we're going to install it at the workspace level. Yarn add dw learner All right, and I'm going to look in my course files and there should be a config learner dot JSON. So copy this file into the root of your workspace. I wanna talk a little bit about what we see in this config file.

[00:01:53]
This first property here, let me copy it in before I forget to do that. The first property packages. It is kind of equivalent to workspaces In our package JSON. Remember this this is where we started, right? See it's also packages slash star. So we have to tell learner about where it can find our packages.

[00:02:20]
You may be wondering, why do we need to specify this if we're already specifying it in our package, JSON. Well, a couple answers here, number one, Lerner works with NPM, in addition to yarn. In fact, this is the second line here we're saying we wish to use yarn, but it could be used with NPM.

[00:02:41]
So NPM doesn't have this concept of workspaces, and that's there needs to be some way To clue learner in about where it can find our stuff. Second thing, learner deals with things like publishing packages. So there may be things that are present in your workspace that you do not wish to learn to manage.

[00:03:06]
In many cases, these will be the same set of folders. But it's convenient to be able to make adjustments if you ever need to be able to be ever have a need to. All right, this third field here version. So right now, we're using a versioning strategy called lockstep.

[00:03:29]
What that means is, if we were to publish everything in this repo, we would get at slack/types. I put this lerna.json in the wrong place, by the way, I'm gonna move it. Was not in my workspace route and it should have been. There it is workspace route. So we would get slack utils one slack types one and every time we make a change this version number will bump for everything.

[00:04:02]
An example of a project that uses this in practice is Babel. So if we go and look at our root level package JSON here, actually the yarn lock would be better So we've got a lot of different, like they're not all exactly the same, but you see a lot of a lot of seven twelves and then a lot of 710 fours, right this is because as Babel evolves All of the core plugins are versioned in lockstep.

[00:04:48]
That does not mean I'm consuming a unified set of like 7 12, 7 12, 7 12, 7 12 I can still, consume a mix, but whenever a change is made, everything is published with the new version number all 50 or so packages so that that's an example of a project that uses lockstep versioning.

[00:05:08]
In practice, the other option we have here is to say independent. This allows the versions of the different packages in my mono repo to float with respect to each other. So if I only change slack slash utils. Only that package will cut a new release. And only it's version number will go up.

[00:05:38]
So the version numbers across my whole project may be different. And this is what you would want to do if you kind of have a collection of things. But the way these packages within the mono repo talk to each other. Might be through their own public API's. And so, someone may consume these things, you know, only one package from the mono repo and they want semantic versioning and to not have to like upgrade a whole bunch of extra stuff.

[00:06:09]
Just because you touch one little thing in one package, right? You don't. You don't need to trigger that kind of churn. Now, it's important to understand the condition I just added there the qualifier. If everything talks to each other through its public API, then semantic versioning is sufficient to describe that you know, it is safe to take in this next version of one package from the mono repo.

[00:06:35]
If you have a lot of private stuff, talking to other private stuff between your packages You probably want to use lockstep because your version numbers are no longer really describing. This is a major, you know breaking change non breaking enhancement, a patch, right like a bug fix that doesn't affect the public API at all.

[00:06:56]
You're not using your version numbers to describe that stuff anymore. You're using version numbers to describe Maybe that same concept but of the whole collection of things, not the safety of moving individual packages within the monitor repo, forward or backward, you're more signaling like these are all meant to work together.

[00:07:17]
These are all mentors together etc. We're gonna start out with lockstep versioning and later we'll change, because this is the simplest way, for now. We're done. All we needed to do I know I've been talking for a little bit but all we need to do is install learner drop that config file in place and let's see what happens.