Explain "monorepo" Like I'm Five

Inspiration:

Did you find this post useful? Show some love!
DISCUSSION (16)

You need an organization system for your legos. We can get you a lot of little bins and you can put each of your lego sets into its own bin. Then, when you want to build the red race car, you pull out the red race car bin and make it. If you want to build the orange plane, you can get out that bin and build it. You can keep the instruction sets for how to build each in its bin. The race car instructions with the race car legos and the plane instructions with the plane legos.

Some day, you're going to want to start combining the legos between the different sets to create your own projects. Maybe that's because you're bored of the car and the plane and want to build a flying car instead or maybe that's because you use Mom's 3D printer to make some new pieces that you want to attach to both the plane and the car. Whatever the case, you now have a choice. You can still keep the legos in their own bin and just know that when you want to build your flying car, you're going to have to get out the bin for the plane and car and put them together. And where do you keep the drawings for how to build your flying car? Maybe we need a 3rd bin for that. As you get more and more lego sets (birthdays, allowance, etc.), you need a lot of bins.

At some point, you might decide it's easier to have one bin and organize the legos within the big bin in a way that makes it easy to assemble any of the lego sets; or any of your own creations. You can even keep all the instruction manuals and your own drawings in that big bin. This one big, organized bin is a "monorepo". It makes it easy to have all the legos you need to build what you want, but it also means that your brother might mess up your organization system or lose some legos (break the build). Since you're all sharing the same bin of legos, you have to have rules and be nice about how you play with them, how you put them back, what you do if you lose or break a piece, etc.

This is a great "like I'm five!"

Thanks, this was a great explanation.

Never take an extremist seriously.

Only extremist call other people extremists...so touché.

One of the most interesting things about mono repos is that Google uses one. Now I will say that have many tools they created to manage the codebase, but it is super interesting. If you have time, this is great talk about it...

Google's Mono Repo

A monorepo is simply the decision to host more than one "project" in a single version control repo. This means branching and other concerns would be shared between projects instead of being independent from one another. It's also possible to share code between "different projects" more easily this way.

I have never worked in this style (or maybe a bit in the past without really thinking of it in these terms).

The concept of what is a separate "project" is fairly abstract, so what is and is not a monorepo might be a topic for debate.

In my universe a question might be "do we want the mobile apps to share a repo with the main dev.to codebase?

These two repos (plus more) could live in a single repo and that might be a good choice (if I agree with the believers in the other thread).

thepracticaldev / dev.to

Where programmers share ideas and help each other grow


DEV

DEV Community 👩‍💻👨‍💻

The Human Layer of the Stack

ruby version rails version Travis Status for thepracticaldev/dev.to CodeTriage badge

Welcome to the dev.to codebase. We are so excited to have you. With your help, we can build out DEV to be more stable and better serve our community.

What is dev.to?

dev.to (or just DEV) is a platform where software developers write articles, take part in discussions, and build their professional profiles. We value supportive and constructive dialogue in the pursuit of great code and career growth for all members. The ecosystem spans from beginner to advanced developers, and all are welcome to find their place within our community. ❤️

Table of Contents

Contributing

We encourage you to contribute to dev.to! Please check out the Contributing to dev.to guide for guidelines about…


thepracticaldev / DEV-ios

DEV Community iOS App

Build Status GitHub License Language Maintainability Test Coverage

DEV iOS 💖

This is the repo for the dev.to iOS app.

Status:

Released first version, more info: twitter.com/bendhalpern/status/106...

Design ethos

We will grow to include more native code over time, but for now we are taking the approach of native shell/web views. This approach lost favor early in iOS days, but I believe it is a very valid approach these days. It is inspired by how Basecamp does things. Our tech stack is a bit different, but the ideas are the same.

m.signalvnoise.com/basecamp-3-for-...

signalvnoise.com/posts/3743-hybrid...

signalvnoise.com/posts/3766-hybrid...

youtube.com/watch?v=SWEts0rlezA

By leveraging wkwebviews as much as possible, I think we can make this all pretty awesome and sync up with our web dev work pretty smoothly. And where it makes sense, we can re-implement certain things fully native, or build entirely native features. Life's a journey, not a destination.

Contributing

  1. Fork and clone the project.
  2. Install Carthage. If you use Homebrew…

Relevant reading:

Why Google Stores Billions of Lines of Code in a Single Repository

PS. love this post, I really feel like it creates a knowledge map from one topic to another that builds really nicely. I definitely encourage more like this. 😄

But if the main advantage of the monorepo is different apps sharing code or modules, is this the case for devto? On the surface I see a Rails + preact app and a swift app which in common have the end goal but not the code. Is it because of some other plan?

I agree, and this is probably correct, but I'm exploring alternatives conceptually at least.

Since our iOS app is predominantly running web views/business logic it seems like there could be an argument for wanting to have a concept of what's latest on the web to run a localhost version of the app while you code on the iOS app via xcode.

It's probably not a change that needs to happen, but it's not inconceivable. Chalk this up to a random thought I'm being overly public about at this point 😄

Legit argument, maybe in the meantime you could bundle scripts to download a Docker image of the backend, start it and be able to point the mobile app to it

Why not use git submodules of the shareable code?

Thanks a lot, this is interesting. I'll try this someday.

I think there are plenty of use cases for having a monorepo, but given what we know about how things work in "Project Manager Land" I'm dreading the day one of my customers watch a YouTube video about the subject and decides we don't need 5 git repositories anymore.

If it works for Google, doesn't mean it will work for you/us/they.

Instead of describing it by myself I share a link which describes it really really easy:

Advantages of monorepos

Short and sweet, but this is a good Twitter thread to read about monoreps from one of the creators of Lerna, James Kyle.

Classic DEV Post from Oct 7

5 Salary Negotiation Rules for Software Developers. Get +20% On Top of Your Market Rate

5 Salary Negotiation Rules for Software Developers. Get +20% On Top of Your Market Rate

Shivam Singhania
Student.

Where the wild code grows

Sign up (for free)