First off the definition:
So now that I’m quite close to being able to start on a rewritten main website, I started thinking about how to structure the code sharing. Obviously it will share a lot of code with the DevCenter so I thought I’d make one “revolutionary web app base” project, which would then be used by both.
That doesn’t sound too complicated yet and could very well be split into its own repo. But I’ve been thinking about what’s the endgame. How many custom web apps will Thrive have in total? If we start adding stuff like a centralized login / registering for use in potential Thrive multiplayer, that’s then 3 separate repos for the apps. Then if we just keep on going rewriting any software I find annoying like Weblate and maybe the wiki and suggestions. That’s a ton of repos. It will be quite a huge pain if dependabot opens 2 PRs for each repo and then also the shared base. Because that will require then updating all of the depos for the new shared base version.
That’s starting to sound like quite a bit of pain. Thus the idea of a monorepo came into my head as the solution. So instead of having all of those separate repos what I could do would be to rename the current ThriveDevCenter repo to something like RevolutionaryWebApps that way the base project as well as all other web apps we’d have can share the same repo. That way the dependabot updates work nicely and aren’t any more work-intensive than they currently are. The only downside I see is that eventually when there’s an absolute ton of code and tests a bunch of extra stuff will be done for each commit, but I don’t see this as much of a threat considering how much difficulty I have in getting anyone to help me out with the devcenter development.
It shouldn’t be too difficult to rename the repo and re-setup the CI jobs and probably add LFS as the main site will use some pretty large theme images. I don’t really expect anyone to discuss this idea, but does anyone have anything to comment on this?
.