Monorepo vs Polyrepo vs Independent Components

Choosing Monorepos vs Polyrepos vs Independent Components for JavaScript projects

As developers, selecting either Monorepo or Polyrepo approach is something we decide at the beginning of a project. And the final decision is made considering the scope, team dynamics, cohesion of modules &, etc.

And what if I tell you that your decision might get challenged with an emerging technology known as Independent Components?

So, this article will explore Monorepos, Polyrepos, and Independent Components and the benefits that help you to select the right project structure.

Monorepos vs Polyrepos

Let’s start by understanding the two models Monorepos and Polyrepos.

Monorepos

As the name implies, Monorepo uses one repository to store all the modules of an application or an entire application suite.

Monorepo representation

The Monorepo structure consists of a single code repository with a hierarchical directory structure that includes several projects. So, for example, you have your backend, frontend, and shared modules as shown below within the same repository.

Structure of a Monorepo

Polyrepos

A Polyrepo is a term we use to say that we use different repositories to store different parts of an application or simply for different applications. The decision behind each repository’s boundary typically revolves around the team governance, release scope, cohesion between modules &, etc.

For example, you may use a different repository to store the frontend code and another for the backend. If there is shared code, you might even create a library project and put it into a package registry for others to reuse.

Polyrepo representation

But, as you can see, having a large number of repositories doesn’t help any team. On the contrary, it will increase the overheads on collaboration, governance, sharing code, managing release lifecycles, and testing.

So, keeping the number of repositories at a manageable level is essential when moving ahead with Polyrepos.

Independent Components

Both Monorepo and Polyrepo look at the Macro approach of project structure and source control. But, what if we look at it the other way around.

What is the minimal unit of a project structure that’s meaningful to define as a unit?

1. If we represent a group of files that has a meaning as a unit (e.g., React Component, Node Modules).
2. Has a lifecycle independent of the rest of the codebase.
3. Has the ability to share the component outside

We have Independent Components.

So isn’t it similar to creating an NPM repository for each component and store them outside? No!

As we all know its not practical to build a frontend, or even a backend by keeping each component in their own libraries. That will add so much overhead as the number of components increases which will limit the productivity of the teams moving forward.

But, what if I tell you, Bit will make each component independent for us while we can focus on developing the application as we used to do. Interesting right?

Independent Components: The Web’s New Building Blocks

With Bit, each component is created as a standalone unit that can be exported (pushed) to a remote scope. Essentially, a repository for each component.

These separate component-repos can be cloned into a single Bit workspace, where they are managed via a single configuration file and composed together to form new components or apps.

Independent Components with a dependency

Having simple building blocks for your application allows you to share code, work in parallel, and significantly reduce your build time.

But, how does it relate to Monorepos and Polyrepos? To understand that, it requires knowing the specifics of how Bit structure your code and its lifecycle. So, let’s take a look into the details first.

Understanding Bit and its Connection to Structure Code differently

Let’s say that you write a React component for a single button with unique styling and designs where you import it into different pages in your React application.

What if you wanted the same styled button for the website for consistency?

You will have to copy and paste your component from the app to your website code (assuming both of them are built using React). If you had an Independent Component for the button, you can import it into the website.

With Bit, all the components in your project became independent by design and exported to a remote scope. So it’s more like a registry in the cloud managed by Bit or even you (you can host your own version since Bit is open source).

It’s quite a novel concept. The best thing is to try it out to understand the underlying concepts and how it works in practice.

You will be amazed to see the abstractions it provides, giving you the perception that you are working on a Monorepo but giving the flexibility to share components outside.

So how do these things connect?

If you build your application as a collection of Independent Components with Bit, it addresses the code structure at two different levels: workspace and remote scope.

Bit as a Monorepo

• With Bit, you can create a workspace, create components independently that belong to multiple projects. (Basically, your workspace is versioned in Git)
• Inside the workspace, each individual component is tracked by Bit and exported to a remote Bit scope, where it’s being versioned.
• Therefore, each of the Independent Components is networked to become an endless virtual Monorepo, that is because bit manages the dependencies between these components.
• If one component references another, it will be through the remote scope, making them virtually independent.
• If a component is modified and exported, all its dependents will be tested by Bit using their Ripple CI, ensuring that the entire dependency tree works as expected.

Therefore, Independent Components offer all of the advantages of a standard Monorepo and extend it by giving flexibility when managing dependencies at more granular levels.

Bit as a Polyrepo

• You can break your application (or suite) into scopes and workspaces.
• Each workspace can be stored in a Git repository in Polyrepo style.
• You can also decide how to group them into Bit Scopes (remote collection of components) with relevant permissions.
• This makes the components sharable across multiple workspaces.

However, there are several limitations when using Bit, which are worth mentioning.

Limitations of using Bit

• Bit supports Frontend development mainly supporting React and React Native and NodeJS at the moment. For Angular or Vue, you have to use their previous version.
• Bit is the best fit for the JavaScript ecosystem code, such as node, UI frameworks, and Typescript.

For your reference, I’ve also created a table that compares each of these styles.

Monorepo vs Polyrepo vs Independent Components

Comparison Table

Conclusion

Simply said, Independent Components is more like a hybrid between Polyrepo and Monorepo having qualities of both worlds.

I hope you got a basic idea of the different approaches. If you have any questions feel free to comment down below. Cheers!