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

Everything as code: How we manage our company in one monorepo

kasava.dev

Post reply on HN
Print view View original

61–70 of 232 posts

Re: Everything as code: How we manage our company in one monorepo

#61

Post by qingcharles »

giancarlostoro wrote: post #2

I used to be against monorepos... Then I got really into claude code, and monorepo makes sense for the first time in my life, specifically because of tools like Claude. I mean technically I could open all the different repos from the parent directory I suppose, but its much nicer in one spot. Front-end and back-end changes are always in sync this way too. I guess I could work with either option now.

I changed my biggest project to a monorepo based on the same issue. I tinker with a lot of the bleeding-edge LLM tools and it was a nightmare trying to wire them all up properly so they would look at the different bits. So I refactored it into one just to make life easier for a computer.

Re: Everything as code: How we manage our company in one monorepo

#62

Post by tedmiston »

mmh0000 wrote: post #53
Denvercoder9 wrote: post #31

Earlier quoted context omitted.

Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.

True but. There's a huge trade-off in time management. I can spend hours OCDing over my git branch commit history. -or- I can spend those hours getting actual work done and squash at the end to clean up the disaster of commits I made along the way so I could easily roll back when needed.

it's also very easy to rewrite commit history in a few seconds.

Re: Everything as code: How we manage our company in one monorepo

#63

Post by Carrok »

codegeek wrote: post #38

I have a question about Monorepo. Do companies really expose their entire source code all in one repo for their devs to download ? I understand that people can always do bad things if they want but with monorepo, you are literally letting me download everything right ?

This is probably different between startups and enterprises. My background is purely startups, and I can't imagine not having access to 100% of the code for the company I work.

Re: Everything as code: How we manage our company in one monorepo

#65

Post by trevor-e »

Denvercoder9 wrote: post #31
sallveburrpi wrote: post #26

Earlier quoted context omitted.

squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess

Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.

Good luck getting 100+ devs to all use the same logical commit style. And if tests fail in CI you get the inevitable "fix tests" commit in the branch, which now spams your main branch more than the meaningful changes. You could rebase the history by hand, but what's the point? You'd have to force push anyway. Squashing is the only practical method of clean history for large orgs.

Re: Everything as code: How we manage our company in one monorepo

#66

Post by williamtrask »

"Conclusion Our monorepo isn't about following a trend. It's about removing friction between things that naturally belong together, something that is critical when related context is everything.

When a feature touches the backend API, the frontend component, the documentation, and the marketing site—why should that be four repositories, four PRs, four merge coordination meetings?

The monorepo isn't a constraint. It's a force multiplier."

Thank you Claude :)

Re: Everything as code: How we manage our company in one monorepo

#67

Post by djhedges »

eddd-ddde wrote: post #10

I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.

We use a mono repo and feature flag new features which gives us the deployment control timing.

Re: Everything as code: How we manage our company in one monorepo

#68

Post by mmh0000 »

tedmiston wrote: post #62
mmh0000 wrote: post #53

Earlier quoted context omitted.

True but. There's a huge trade-off in time management. I can spend hours OCDing over my git branch commit history. -or- I can spend those hours getting actual work done and squash at the end to clean up the disaster of commits I made along the way so I could easily roll back when needed.

it's also very easy to rewrite commit history in a few seconds.

If I'm rewriting history ... why not just squash?

But also, rewriting history only works if you haven't pushed code and are working as a solo developer.

It doesn't work when the team is working on a feature in a branch and we need to be pushing to run and test deployment via pipelines.

Re: Everything as code: How we manage our company in one monorepo

#69

Post by esafak »

williamtrask wrote: post #66

"Conclusion Our monorepo isn't about following a trend. It's about removing friction between things that naturally belong together, something that is critical when related context is everything. When a feature touches the backend API, the frontend component, the documentation, and the marketing site—why should that be four repositories, four PRs, four merge coordination meetings? The monorepo isn't a constraint. It's…

It wrote the code, so it's best placed to write the copy too.
Post reply on HN