I'm 🪙 coining the term weak monorepo for a solution to specific problem.
Imagine a consultancy where everyone needs the same generic tooling. Each person might work on different projects and some people might not be security clear to see every project 👀 due to top secret NDA's.
You then have the dilemma of packing every project with the same tooling over and over, keeping them all up to date.
Or having a separate bunch of tooling which points to a project or projects, not ideal.
How do you solve this?
The solution is pretty simple, create a monorepo as normal but then git ignore the packages / projects folder whatever you call it. Then instead if monorepo packages in one repo, keep the project as repositories of thier own cloning as needed into the packages / projects folder.
I believe this is the best of both worlds.
Just make sure your CWD is in the package your working in when using GIT other that that it's business as usual.
Oh but also you can individually branch your packages like a sane system of organisation.
This solution is something I am trailing at work and we will see how everyone likes it.
Top comments (2)
I have a gut reaction like this is an abuse of git but also if I'm honest I can't really find why it'd be so bad to do this.
So it's intriguing and a bit uncomfortable, and I'd be happy to hear a follow-up article next year or whatever after you've run with it for a while.
I know what you mean, bit of a mind F at first, but you know what, some things are wierd because nobody does it. Submodules exist, Subtrees exist, they all don't seem to solve the problem, this problem, the pick and mix style of development. I am happy to follow up in 6 months are something like this.