3 ms·
>> I prefer to use a monorepo structure There is nothing more annoying than tons of little repos all of which containing tiny projects with a few hundred lines
by osigurdson 1y ago
>> I prefer to use a monorepo structure
There is nothing more annoying than tons of little repos all of which containing tiny projects with a few hundred lines of code but (of course) you need most / all of them to do anything. Use a mono repo until there is some obvious reason to split it up imo.
- sethammons 1y agoin my experience, repo by "area" works the best. This usually means by team, but you don't want a team restructure to cause code relocation issues. And, yes, only when the org pressures push for it. On the flip side, we have an org with 50+ teams and our operations team is pinning for a monorepo. They are just fine with one team's push forcing N teams to have an unexpected deploy and recycling of caches, connections, etc. Not to mention what will happen when team A doesn't have time to deal with team B's merge due to other org pressures.
- osigurdson 1y agoWhy do they want a mono repo though? What are the problems with the current situation.
- sethammons 1y agoconsistent CI/CD, code discovery and sharing, and (I contend falsely) protection against backward compatibility issues.
- MonkeyClub 1y agoI got the impression that TFA speaks of a monorepo in the sense of not splitting the backend and the frontend into two different repos. For personal projects, though, I get the value of an actual small projects monorepo.
- osigurdson 1y agoI'm not talking about personal projects. If you have <100 people, mono repo imo.