Everything as code: How we manage our company in one monorepo • Hacker News Board

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

#11

Post by bulbar » Tue, Dec 30, 2025, 8:40 PM UTC

conartist6 wrote: post #9

I really want the world to move on from monorepos to multirepos. Git submodules set multirepos back by 10 years, but they still make more sense. The are composable!

My impression is that the world moved on from multirepo to monorepo and I vaguely remember that git submodules have some serious gotchas.

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

#12

Post by radial_symmetry » Tue, Dec 30, 2025, 8:40 PM UTC

I promise I only self promote when it is relevant, but this is exactly what I am building https://nimbalyst.com/ for.

We build a user-friendly way for non-technical users to interact with a repo using Claude Code. It's especially focused on markdown, giving red/green diffs on RENDERED markdown files which nobody else has. It supports developers as well, but our goal is to be much more user friendly than VSCode forks.

Internally we have been doing a lot of what they talk about here, doing our design work, business planning, and marketing with Claude Code in our main repo.

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

#13

Post by giancarlostoro » Tue, Dec 30, 2025, 8:44 PM UTC

valzam wrote: post #6

emzo wrote: post #3

Earlier quoted context omitted.

Opening Claude from the parent directory is what I do, and it seems to work pretty well, but I do like this monorepo idea so that a single commit can change things in the front end and back end together, since this is a use case that's quite common

Except of course rollout will not be atomic anyway and making changes in a single commit might lead Devs to make changes without thinking about backwards compat

This is where unit testing / integration testing should be implemented as guard rails in my eyes.

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

#14

Post by fragmede » Tue, Dec 30, 2025, 8:44 PM UTC

radial_symmetry wrote: post #12

I promise I only self promote when it is relevant, but this is exactly what I am building https://nimbalyst.com/ for. We build a user-friendly way for non-technical users to interact with a repo using Claude Code. It's especially focused on markdown, giving red/green diffs on RENDERED markdown files which nobody else has. It supports developers as well, but our goal is to be much more user friendly than VSCode forks.…

So the insane thing I do is I don't use worktrees. I am using multiple Claude code instances on the same project doing different things at the same time like one is editing the CSS for the login screen while another one is changing up the settings section of the project.

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

#15

Post by nithril » Tue, Dec 30, 2025, 8:44 PM UTC

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.

Is there any concern/issue regarding Claude’s context limit?

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

#16

Post by giancarlostoro » Tue, Dec 30, 2025, 8:45 PM UTC

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.

I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for your next PR, waste of time when I should be able to pull down master / dev / main / whatever and merge it into my working branch. I guess this is another reason I prefer the forking approach of github, let devs have their own sandbox and their own branches, and let them get their work done, they will PR when its ready.

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

#17

Post by sethammons » Tue, Dec 30, 2025, 8:45 PM UTC

people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api.

At some point, you will have many teams. And one of them _will not_ be able to validate and accept some upgrade. Maybe a regression causes something only they use to break. Now the entire org is held hostage by the version needs of one team. Yes, this happens at slightly larger orgs. I've seen it many times.

And since you have to design your changes to be backwards compatible already, why not leverage a gradual roll out?

Do you update your app lock-step when AWS updates something? Or when your email service provider expands their API? No, of course not. And you don't have to lock yourself to other teams in your org for the same reason.

Monorepos are hotbeds of cross contamination and reaching beyond API boundaries. Having all the context for AI in one place is hard to beat though.

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

#18

Post by maxvirrozeito » Tue, Dec 30, 2025, 8:47 PM UTC

conartist6 wrote: post #9

I really want the world to move on from monorepos to multirepos. Git submodules set multirepos back by 10 years, but they still make more sense. The are composable!

For me, integrating features that spans multiple repositories means coordinating changes, multiple PRs, switching branches on many repos to do testing. Quite time consuming. I did use submodules but I find monorepo easier to manage

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

#19

Post by sails » Tue, Dec 30, 2025, 8:47 PM UTC

I like this for adjacent things too.

Company website in the same repo means you can find branding material and company tone from blogs, meaning you can generate customer slides, video demos

Going further, Docs + Code, why not also store Bugs, Issues etc. I wonder

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

#20

Post by eddd-ddde » Tue, Dec 30, 2025, 8:49 PM UTC

giancarlostoro wrote: post #16

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.

I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for your next PR, waste of time when I should be able to pull down master / dev / main / whatever and merge it into my working branch. I guess this is another reason I prefer the forking approach of github, let devs have their own sandbox and their own branches, and…

I'm very fortunate to not have to use PR style forges at work (branch based, that is). Instead each commit is its own unit of code to review, test, and merge individually. I never touch branches anymore since I also use JJ locally.