Monorepos are being hyped lately in the single page application development world, because of the flood of tools to utilise them in that field. Yet they are not a new thing at all. They have been here since the early 2000s. This blog post is about what monorepos are, why we started with them and moved away from it. And finally why it's being hyped right now.

This blog post is part of a series of three posts. The second post (upcoming) is about the benefits and the final is about the drawbacks. Stay tuned.

What are monorepos?

A common misunderstanding is the terminology with monorepos and monoliths. Monoliths refer to a type of software architecture. While monorepos refer to a concept of utilising version control systems in an organization or a team.

A monorepo is the idea of having all the necessary code for a complete application in one repository. That can mean:

two applications: REST API and SPA can live in the same repository, useful to implement backend and frontend functionality with the same merge request.
multiple component packages for an SPA
a collection of microservices
a mix of all those three maybe.
etc.

What are the alternatives? What are we using today?

Besides monorepos a lot of organizations utilise polyrepos. They have the big benefit of team autonomy. That means, that every team in an organization can decide themselves, what dependencies they install, what build tools they use and when to release (and what version name they will use).

Although team autonomy is great and required to grow as an organization, it comes with his little brother: isolation. More on that later.

Why was it first popular and then stopped being popular for quite a long time?

Like mentioned earlier. Since the early 2000s they have been around. What happened to them? What made it unpopular to stick to monorepos?

Why has it been "the way to go"?

Not following a monorepo approach would mean that you would have different places with different pieces of code. There will be code in your application that depends on the package from the other repository.

In order to build the whole application you would have to build libraries first and later assemble everything. Back in the days this would have been a huge task to do and might also result in a lot of overhead for developing an application back. That was not bearable.

Commercial software development become popular

Later in our timeline software development departments became larger and more difficult to manage. Splitting them only works as great as the workflow behind it works and the need for team autonomy brought the new era of polyrepos.

Polyrepos have the great benefit of team autonomy which grants each team the freedom of decision for a lot of things.

Often there are some restrictions, like which VCS to use and maybe what CI environment they need to build their artifacts with. However with polyrepos they are free to:

design their own contionous build pipeline
define their own code standards
select the tools to build something
define the version of a package
etc.

Two sides of the medal

You are free to do it the way you want, but polyrepos bring up other problems. Namingly isolation.

Imagine that you to share some specific code from your repository. You would have to create a new repository and move that "to-share-code" over there. Configure it, publish it, maintain it.

Back to monorepos

Nowadays things have changed. New ways of cooperation have emerged and technologies have evolved and the cons of polyrepos showed their side-effects.

It always was quite a hustle to maintain a monorepo in the npm world. By the new feature of npm / yarn workspaces, this became easy.

Great minds built tools on top of the existing npm workspace / yarn workspace technology and that's why we see a great demand for monorepos.

Why you should care and the dark side of a monorepo

However there is more to itI will talk about them in the upcoming posts. Expect:

the bright side of monorepos (on 24th Jan)
the dark side of monorepos (on 31th Jan).

Don't ever miss a post again

Subscribe to the newsletter to always stay up to date and never miss valueable free knowledge!

Monorepos (1/3) - What are Monorepos?