4 ms·

I don't have a lot of experience with monorepos but I've found them very useful for: - Simple projects with a server and an SPA component - frontend and backen

I don't have a lot of experience with monorepos but I've found them very useful for: - Simple projects with a server and an SPA component - frontend and backend code for the same feature is on the same feature branch, can be tested and reviewed together. - Projects with a couple of microservices that share some common libraries - these libs can be directly referenced by the microservices instead of being published on an internal package server. This of course has its drawbacks too but overall, the benefits have outweighed them.

bweitzman 6y ago
If you don't publish packages anywhere, wouldn't that mean that if you update some library with a breaking change, you have to update all call sites? Maybe the fix for that is to never make breaking changes, but that has drawbacks as well...
- detaro 6y ago
  It's a tradeoff. Yes, you can only remove something if all callsites are gone, need to take care of breaking changes etc, but on the other hand you have clear insight into that and individual components can't as easily drag behind and require you to keep old versions around/maybe even backport fixes/... And ideally a monorepo workflow gives you the tools to a) find all callsites, b) run tests to ensure your changes won't break anything, c) apply changes in lockstep. Those tools are an engineering effort, but the equivalents for a large multi-repo setup are too.