Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monorepos: Please don’t

medium.com

Post reply on HN
Print view View original

121–130 of 402 posts

Re: Monorepos: Please don’t

#121

Post by jayd16 »

olingern wrote: post #37

I’ve found monorepos to be extremely valuable in an immature, high-churn codebase. Need to change a function signature or interface? Cool, global find & replace. At some point monorepos outgrow their usefulness. The sheer amount of files in something that’s 10K+ LOC ( not that large, I know ) warrants breaking apart the codebase into packages. Still, I almost err on the side of monorepos because of the convenience th…

Hold on, are we talking about monorepos, ie a set of projects with shared change history (and possibly 'build it all' type tooling) or single monolithic apps?

I'm seeing these two things conflated in this thread.

Re: Monorepos: Please don’t

#122

Post by icebraining »

chvid wrote: post #92

Does a lot of the pain from a monorepo come from trying to use a tool - Git - that is explicitly designed to support distributed repositories? Wouldn't things be easier if you used eg. Subversion instead? That is a tool that was designed around a client/server paradigm and had a single repository as its main use case.

Git was designed for a monorepo (the kernel). When people talk about monorepo, they mean a single history line.

Re: Monorepos: Please don’t

#123

Post by woolvalley »

jonex wrote: post #21

Seems like the main point is that you'll still need to add additional tooling (search, local cloning, build, etc) to handle scaling, something you can do just as well with polyrepos. Conversely, for polyrepos, you can add tooling to fix issues with dependency management and multi-project changes/reviews. However, the author figures that monorepos engourage bad code culture and points out that Git is hard to build a m…

What is the tooling for multi-repo atomic synchronized commits? Monorepo's give you that for free, which is the reason why I think monorepo projects exist. SVN kind of gave you partial checkouts, which was helpful.

Re: Monorepos: Please don’t

#124

Post by icebraining »

madhadron wrote: post #76

The truth is that you're not going to get to make this decision. If you're starting greenfield, you're going to start a single repo for your project. If that greenfield is the whole company and everything is part of that project, you get a giant monorepo. If greenfield is a new division that's not part of another project, you're going to create a new repo, and now you're in a polyrepo environment. Which way it goes i…

I've started a greenfield project that involved multiple modules, and I created a different repo for each, but I could just as easily have created a single repo.

Re: Monorepos: Please don’t

#125

Post by Xylakant »

ajuc wrote: post #31

I call bullshit on "our repository is too big for one machine". Seriously, you have over 1 TB of code and 100 people wrote it?

adding raw versions of binary assets (designs, video, ...) can quickly lift a repo beyond a TB. Now, you could say "don't do that", but there's valid use cases where you'd want to track all binary assets as part of the development cycle.

Re: Monorepos: Please don’t

#126

Post by icebraining »

forrestthewoods wrote: post #79
thehazard wrote: post #12

Better title would be "Monorepos don't fit with my particular use case."

I strongly agree. I hate this style of blog post. Telling people what they should or should not do is generally absurd. Every situation is unique and you can't possibly know another project's requirements or acceptable trade-offs. A better approach, in my opinion, is "Here's what we did and why". The author clearly has experience in the area. Great! Tell me about your problems. Tell me about your attempted solutions…

Isn't your own post telling people what they should and should not do (specifically on how to give advice)?

Re: Monorepos: Please don’t

#127

Post by btschaegg »

wcdolphin wrote: post #97
btschaegg wrote: post #94

Earlier quoted context omitted.

I think there's a nuance to this that should be pointed out: Monorepos allow you to do very bad hacks (I need this other component over there; let me just put in a Symlink. Done.). And if people can, they will use those hacks. If you split your repo up from the get go, the worst thing you can get that you'll have to assemble multiple distinct, well-encapsulated (in terms of project structure) things into one. In Git,…

No. The worst case is that the engineering team spent more time working on “well encapsulated projects” than on the most important project for their business and are all now out of jobs. Most companies don’t fail because of tech debt. And certainly not because of version control tech debt.

Not exactly. (At least small) companies can go out of business because of bugs. And one great way to "achieve" said bugs are implicit dependencies hidden from developers that didn't introduce them.

> The worst case is that the engineering team spent more time working on “well encapsulated projects” than on the most important project for their business

I'm not really sure how I should read this. Don't you use your repos to solve business problems? Why should that change because of the repo layout?

Re: Monorepos: Please don’t

#128

Post by chvid »

icebraining wrote: post #122
chvid wrote: post #92

Does a lot of the pain from a monorepo come from trying to use a tool - Git - that is explicitly designed to support distributed repositories? Wouldn't things be easier if you used eg. Subversion instead? That is a tool that was designed around a client/server paradigm and had a single repository as its main use case.

Git was designed for a monorepo (the kernel). When people talk about monorepo, they mean a single history line.

It is just the feeling I get when I see how it is used. That it is being misused.

If you have a corporate setting with a single Jira/Stash/Bamboo installation keeping all the company's stuff in a single central place. Then this design where git copies (clones) the full repository on the local machine just seems like a misfit and source of lots of pain (ie. just being slow and at times unstable, local repository not pushed back to origin, multiple history lines etc.).

It seems to me that things would have been better served with a more primitive client/server orientated tool like Subversion.

Re: Monorepos: Please don’t

#129

Post by StreamBright »

curtis wrote: post #32

My advice is that if components need to release together, then they ought to be in the same repo. I'd probably go further and say that if you just think components might need to release together then they should go in the same repo, because you can in fact pretty easily manage projects with different release schedules from the same repo if you really need to. On the other hand if you've got a whole bunch of component…

So why is that? Why do we ned to couple together the software development efforts with release? Based on my experience there is no difference between the monorepo vs multirepo approach from the deployment point of view.

Re: Monorepos: Please don’t

#130

Post by jhasse »

jogjayr wrote: post #107
btschaegg wrote: post #94

Earlier quoted context omitted.

I think there's a nuance to this that should be pointed out: Monorepos allow you to do very bad hacks (I need this other component over there; let me just put in a Symlink. Done.). And if people can, they will use those hacks. If you split your repo up from the get go, the worst thing you can get that you'll have to assemble multiple distinct, well-encapsulated (in terms of project structure) things into one. In Git,…

> Monorepos allow you to do very bad hacks (I need this other component over there; let me just put in a Symlink. Done.). Why would you put in a symlink? You could just provide a path to the actual component and import it into your project. > the worst thing you can get that you'll have to assemble multiple distinct, well-encapsulated (in terms of project structure) things into one When you have multiple repos, you a…

> Why would you put in a symlink? You could just provide a path to the actual component and import it into your project.

Where do I need to put the path again? Ah what the heck, I'll just add a symlink inside a folder that's already somewhere in the build definitions.

Post reply on HN