4 ms·
The one thing I hate about monorepos is nothing ever gets versioned, packaged, and shipped. Polyrepos are workable, the way to do it is to actually version, sh
by dheera 7mo ago
The one thing I hate about monorepos is nothing ever gets versioned, packaged, and shipped.
Polyrepos are workable, the way to do it is to actually version, ship, and document every subcomponent. When I mean ship, I really mean ship, as in a .deb package or python wheel with a version number, not a commit hash. AI can work with this as well, as long as it has access to the docs (which can also be AI-generated).
- giorgioz 7mo agoThe monorepo make it easier to ship the overall product but harder to ship parts of it. I've used a monorepo for the past 13 years and I got all shared packages with version 0.0.0 and I still haven't figured out a simple way to share just some parts of it like a CLI. Does anyone have a monorepo and publishes NPM packages with source code of only that folder? Sub-gits required to pull in multiple places...
- fixxation92 7mo agoI've got about ~15 repos for a project and I just start Claude Code in the parent directory of all of them, so it has clear visibility everything and cross-reference whatever it needs.... super handy.
- dezgeg 7mo agoThe best thing about monorepos is nothing ever gets versioned and packaged. That means, a subcomponent can just make a needed change in the supercomponent as well, and test and the ship the subcomponent without excess ceremonies and releases.
- dheera 7mo agoThat strategy sucks when you have 15 supercomponents depending on 1 subcomponent, you want to rewrite the subcomponent, and now you have to deal with all 15 of them and get codeowners approvals from all 15 of those teams. In a polyrepo org you just release version 2.0 of the subcomponent and upgrade the 1-2 of the 15 teams where the 2.0 features are actually needed now. The rest of the users can upgrade on their own schedule.