Monorepo Tooling Q&A

[00:00:00]
>> Mike North: We have a question online.
>> Speaker 2: Are mono repos and micro front end architecture interrelated at all?
>> Mike North: They are, often you'll have micro front-ends arranged into packages within a monorepo, right? So micro front-ends is the concept of instead of having a UI monolith, you're sort of composing together subparts of it.

[00:00:23]
And that's like a great example of where you might want to model each of those as a distinct package. So there's strong encapsulation or encapsulation that you have a high degree of control over as it relates to the contract between two micro front ends or their contract with some core part of the UI that sort of cuts horizontally across all the micro front ends.

[00:00:48]
>> Speaker 2: Are monorepos a good setup for creating a library? For instance, if I have one package with multiple projects and I want to serve that as a library.
>> Mike North: If you have one package with multiple projects, I would flip that around and say it's probably if you have one project with multiple packages.

[00:01:08]
So say you had a project where it was consumable as a library, but also you have a CLI for people that just want to use it, use some part of it in a terminal. Say it's for image resizing or something. Well, you could say, look, there's this core thing that's the library.

[00:01:25]
And then on top of that I'm going to build the cli, but I want to develop and evolve these things together. Like when I add a new feature or I make some change to the way I represent data, I want this to all be something where I can have a single git commit and kind of keep these synchronized over time.

[00:01:44]
And in that case, I'd break them up into two packages within one project.
>> Speaker 2: Your opinions on turborebo versus nx?
>> Mike North: My opinion is they both meet. Like, I like them both, and they work a similar way. This concept of having. Well, like, there are two concepts there, which we'll get to more deeply when we start talking about nx.

[00:02:11]
One is the idea of cached build steps. You can think of this as almost like a pure function where you can state my linting task. It's the result of running that task both in terms of did it pass or did it not pass? And what was the output to the cli?

[00:02:31]
What was the output in the terminal or what was the file it generated? If you have your linter piping out to a file, if that's the output and the input's the source code and you can state, yeah, this is like for a given input the output will always be the same.

[00:02:46]
Well, then you can cache that instead of actually running your linter every single time. You could say, you know, we haven't really touched anything since we ran this, including the version of eslint that's being run. So I'm just gonna spit the same output out. I'm gonna skip the step where we run exactly the same thing and I'm just gonna give you the output.

[00:03:10]
So that's this concept of like a cached task, if you will. And then what turbo repo or TurboBuild and NX both do is they will then have a cloud service where you can push these cached results. And what that means is even across your development team, you get the idea of sort of getting a fingerprint on the inputs and preserving the same output and you can sort of benefit from, from that across your team or in CI across multiple jobs.

[00:03:42]
So it's sort of like that second step is more about more than just you sharing the same cache and getting the benefits of the same cache. And we're gonna do that. We're going to, as we dive into NX and LERNA as well, we're going to see the benefits of that.

[00:04:00]
It's an incredible speed up for those tasks where the same inputs will always yield the same outputs. And it's up to you to state that that's the case for a given task.
>> Speaker 3: Given all of these benefits of monorepos, we're kind of going through. It almost sounds like you should always choose a monorepo, but obviously that's not the case.

[00:04:22]
What do you kind of look for when you're trying to decide if a project should be a monorepo versus poly repo? Like, what are the indicators you're kind of looking for there?
>> Mike North: Great question. For me, the most significant bit is really about what is the interrelatedness of the packages that would be within this project?

[00:04:44]
The project, let me answer this in two ways. If you're thinking about a project on GitHub, let's take Babel for example, for taking very modern JavaScript and transpiling it so that older runtimes can execute it well, you can have a nice set of Babel plugins in there, you can have the Babel core package, you can have the Babel cli and there's a lot of entanglement.

[00:05:12]
There would be a lot of extra work if those were each modeled as a totally separate thing. Now, at a company level, where the commonality factor comes in, the reason for grouping things together. It's usually about having some fairly sophisticated tooling and conventions that are applied that would be otherwise very difficult in a poly repo ecosystem to enforce.

[00:05:39]
So that's probably number one. And then number two, if there's a lot of pain that some community, be it a company or people working on an open source project, if there's pain associated with keeping everybody upgraded, were you to go the poly repo path. Often a monorepo is something to aim for.

[00:05:59]
But here are examples of things where I would not necessarily reach for a monorepo. Like if you're building a little node library that's sort of self contained and it has, you know, it has like a clear reason for existence, there's really no convenient place to sort of start dividing things up.

[00:06:17]
Or if you were dividing things up, it would just be for your own like internal purposes to get like encapsulation boundaries. Well, there are other ways to do that. I think at that point you're going to see that it takes a little bit to get these set up.

[00:06:32]
Now once you are set up, it's fairly easy to manage them with some of the tools I'm going to show you. But at that point it wouldn't necessarily be worth it to me. If you have a CLI tool you're building that's for image manipulation or something like that, maybe, maybe it makes sense to just consider that to be like a monolith tool and not divided into sub packages.