The Case for (and Against) Monorepos on the Frontend

Although monorepos are still primarily the domain of early adopters, there’s growing interest in using monorepos over polyrepo.

We wondered how monorepos might benefit frontend developers after Vercel added support, so we spoke to Victor Savkin, co-founder and CTO of Nrwl, which makes a monorepo/CI tool called Nx. Nrwl is also the maintainer of the open source monorepo tool Lerna.

Defining Monorepo

First, it’s important to understand what a monorepo is. Yes, it’s a single repo for a web project or application, but that doesn’t mean monorepos are a monolith that simply contains all the code. Monorepos are a way to bring order to what otherwise might be a “melluva hess”, as my government teacher used to say. Monorepo tools like NX, Lerna and TurboRepo help establish order in the repo, Savkin said.

“It’s a technical solution to a human problem, which is reducing the cost of collaboration,” Savkin said. “That’s why the monorepo is a lot more similar in terms of impact to something like GitHub than to something like a bundler, because a bundler is a technical problem. With a monorepo, it has to do things fast and all this stuff, but the impact is more… now teams can work together much faster, employees can deliver things much faster.”

That’s why team buy-in is so important, he added.

“The cost of collaboration basically goes down by a lot in a monorepo,” he said. “That’s the main advantage of it, that you basically want to reduce collaboration cost to something that is smaller.”

In fact, collaboration is so key, that if an organization has two separate development teams — perhaps because of an acquisition — that seldom interact, it’s probably best to keep them separate, rather than move to a monorepo, he added.

What ‘Drives’ Monorepos

Savkin compared monolith development to a road with no traffic lights or laws — people are just riding on the road very crazily, he said, but maybe it’s not a problem as long as only a few people are using the road. But when the road starts to see traffic of 100 people, it leads to accidents. To address the problem, multiple roads — polyrepos — are created to ensure the traffic can flow without bumping into each other.

“We have multiple roads. I have my own private road and [on] my own private road, I drive in a particular way, and I don’t want anyone to tell me how I drive,” he said, but adding that “it’s hard to integrate [that private road] into a larger system.”

Monorepos offer an alternative where there are traffic laws and stop signs, which makes it easier to integrate and scale.

“A repo is not just one unit, but several units with explicit relationships between units,” Savkin explained.

Frontend Benefits

Monorepos aren’t just for enterprise applications and large companies like Google, Savkin said. As it stands now, though, polyrepos tend to be the most common approach, with each line of business or functionality having its own repo. Take, for example, a bank. Its website or app might have a credit card section and an auto loan section. But what if there needs to be a common message, function or even just a common design change across the divisions? Polyrepo makes that harder, he said.

“Now I need to do a coordination thing with team A, team B,” Savkin said. “In a polyrepo case, it can take many months.”

In a monorepo, it’s easy to make that one change in as little as a day, he added. It also enables sharing components and libraries across development teams.

Monorepos helped Jotfrom, an online forms company based in San Francisco, reduce its technical debt on the frontend, according to frontend architect and engineering director Berkay Aydin. Aydin wrote last week about the company’s move to a monorepo for the frontend.

“We don’t have multiple configs or build processes anymore,” Aydin wrote. “Now, we’re sure every application is using the same configurations. For example, if we update our browser support, we know every part of the company gets the same browser support.”

He added it’s easy to share code in seconds using the pnpm workspaces feature and some internal boilerplates. Other benefits Aydin listed were:

• A common development environment, which makes it easier to create common commands;
• Better onboarding for new employees;
• Easier refractoring;
• Reduced total build times; and
• Dependency awareness, because developers can see how the applications and libraries are connected to each other.

The Downsides

Aydin also shared the downsides of monorepos and how his team addressed them. The downsides he cites are:

• It’s hard to migrate existing repos to monorepos;
• Making critical changes means working on the weekends or off-times if the source repo is actively in development;
• Managing the build queue;
• Hard-to-debug caching; and, predictably,
• Less freedom for devs. It’s easier to try new technologies on a single repository, he wrote.

Savkin acknowledged that it can be hard to migrate to a monorepo, but it’s not a technical issue; it’s an organizational one.

“The harder part is to say, ‘Well, now can I rework the app so I can take advantage of the monorepo tool’ — for example slice it more, introduce more partitioning [or] share more code,” he said. “That’s harder because that requires architecture thinking. Just mechanically saying, I have two apps, I want to put them in the same monorepo and share a component — that’s trivial; that you can do within a day.”