loading...

Discussion on: Why might a project/company use a monorepo?

Collapse
wuz profile image
Conlin Durbin

We switched to a monorepo at my last company. I really, really liked it. The reasons why:

When dealing with a frontend and a backend that are disconnected, it makes working with another developer a lot easier. You can both check out the same branch to start, then start building around that feature branch, without managing two different repos feature branches.

It makes using shared components a lot easier. We had a few products that we were working on that shared a lot of components. We tried using a seperate git repo for the components and installing that as a package via npm, but that was impossible to maintain across multiple branches and versions. Once we switched, we just set up a webpack alias and accessing ~components/COMPONENTNAME was all you had to do to get the component. We also did the same for shared Ruby components/classes.

It makes documentation a lot easier too, you can have a separate folder for the documentation at the root level and set up builds based on that folder.

You also don't run into mismatches with the frontend and backend repos, where you haven't checked out the correct branch in one or the other and so don't have something you expect to exist.

There were other benefits, but those were the biggest ones I could think of. I'd be happy to answer any questions about this, if anyone has any!

Collapse
hawicaesar profile image
HawiCaesar

Did you have cases when the shared components needed to be customised ...or put another way were there instances where you had to reduce dependency on the shared components ?

Collapse
ben profile image
Ben Halpern Author

Any problems with issue clutter or generally too much going on in one environment?

Collapse
wuz profile image
Conlin Durbin

We didn't use Issues so much, which might be a consideration. This was a for the companies code and so we tracked bugs/issues in a project management tool. I think proper standards and structure can mitigate a lot of that though, especially with Github's new tooling around issues/suggestions.

As far as too much going on, there were a few cases where we could have named something better. Sometimes two projects would have the same file name, and if you weren't paying attention to that, you could edit the wrong code. Better naming/more attention could have fixed that though. From a devops side, I think it made a lot of things easier. New developers could get set up quickly (just a single git clone) and all the code for deploys was in the same repo as the application code.