> shoving all of these ...

I feel like you're being snarky but, regardless, I'm curious to hear your reasoning for the first paragraph. being a monorepo helps us share code across 50 different apps without falling into a submodule/dependency hell.

What's shared between the "Property Management" and "Photo Studio"?

The UI frameworks already exist, there's 0 reason to share more things between them. That is, unless it has a slopped revolutionary(tm) UI framework #1000.

I might be missing something but inspecting a few of them the testing seems quite thin. I won’t do anything now without layers of controls for agent coding. Just for testing — near 100s for v8 coverage, property, mutation, fuzz, chaos, contract, bdd e2e, api and playwright exploratory mcp. Long term maintenance of all of this is going to need a ci/cd that puts all that through a ringer around the clock.

there are other ways to share code than a monorepo, namely independently versioned packages. you say dependency hell but if you're in control of everything you're in the best position to avoid that if you put thought into it. with a monorepo you could actually get worse results in some cases. say i change something in a graphics api for sudoku and suddenly the zoom clone doesn't work. yuck. i only buy the monorepo argument for systems of code that actually need to be deployed in sync, like server/client stuff or larger. iirc google has a massive monorepo for nearly all of their production code because basically all of it works together (server/client stuff, auth, etc)

also a monorepo like this is worse for human interaction, if you care. what if someone only wants to pull and work on sudoku? now they have to get everything else. issues and pull requests are also more annoying to varying degrees depending on use.

for this project, doesn't look like much effort has gone into sharing assets.

Monorepo's don't solve dependency hell. They amplify it.