3 ms·

> You can't split monorepos after the fact, at least not without immense costs. Sure you can. The difficulty of doing so depends on many (many) factors. If you

> You can't split monorepos after the fact, at least not without immense costs. Sure you can. The difficulty of doing so depends on many (many) factors. If your team does their job well then the costs won't be immense. It might be annoying, but not that hard. Speaking in absolutes or platitudes solves nothing. Sometimes monorepos make sense. Sometimes polyrepos make sense. It's entirely dependent on what your company does.

adrianN 8y ago
Of course, if everybody is very diligent in keeping things in the monorepo distinct and independent, then it's easy to split it later on. But relying on constant diligence doesn't work out in the long run in my experience.
- Lio 8y ago
  It's not like polyrepos solve the long term diligence problem though. E.g. if relying solely on a package manager to to keep coupled things in lock step, you need make sure that version numbers are kept up to date for every little change made to every library. You can easily end up with a situation where someone in another team makes a small change but doesn't change the lib version number. That's a people issue but it does happen. You can get round that by using a repo SHA but now you two things to keep up to date for every library. Like wise you'll have to be diligent in versioning APIs. Anecdotally I've found it easier to keep things in lock step when in a single repo and using a single pull request for each story than I have where separate teams have to keep separate repos in sync. Both work but the monorepo approach worked better for the projects I've worked on. It just lead to less moving parts and more repeatability when there's a single SHA to watch. I also have been luck enough that I haven't worked on a project so large that we couldn't build a monorepo on a single machine with "normal" build tooling.

3 ms·

> You can't split monorepos after the fact, at least not without immense costs. Sure you can. The difficulty of doing so depends on many (many) factors. If you

by 0xFACEFEED 8y ago

adrianN 8y ago
Of course, if everybody is very diligent in keeping things in the monorepo distinct and independent, then it's easy to split it later on. But relying on constant diligence doesn't work out in the long run in my experience.
- Lio 8y ago
  It's not like polyrepos solve the long term diligence problem though. E.g. if relying solely on a package manager to to keep coupled things in lock step, you need make sure that version numbers are kept up to date for every little change made to every library. You can easily end up with a situation where someone in another team makes a small change but doesn't change the lib version number. That's a people issue but it does happen. You can get round that by using a repo SHA but now you two things to keep up to date for every library. Like wise you'll have to be diligent in versioning APIs. Anecdotally I've found it easier to keep things in lock step when in a single repo and using a single pull request for each story than I have where separate teams have to keep separate repos in sync. Both work but the monorepo approach worked better for the projects I've worked on. It just lead to less moving parts and more repeatability when there's a single SHA to watch. I also have been luck enough that I haven't worked on a project so large that we couldn't build a monorepo on a single machine with "normal" build tooling.