monorepos
Monorepos are awesome!
A 'monorepo' is a single repo containing multiple interconnected projects.
Often teams try to break up projects into separate git repos - this seems beneficial in some ways, but it adds overhead and generally hurts intangibles like discoverability and experimentation.
Monorepos support a low barrier to entry for new ideas
Monorepos have less overhead for fixing features across libraries
Multi-repos introduce version-control dependency hell
Does this hash work with that hash? Do we now need to run tests for multiple versions of our apps?
Monorepos accumulate capabilities
As features are added, capabilities are created and brought up to speed, and don't need to be re-implemented.
Backlinks
Ralphie is a library for useful clojure / babashka apis.
It provides namespaces and functions for integrating with whatever tools I use.
The gist: bash-like scripting and automation libraries via babashka and repl -driven development.
Originally targetted linux cli helpers, but expanded to some osx use-cases as well.
Example namespaces: emacs, tmux, browser, git, spotify, rofi.
There's a gap in the godot ecosystem - how best to manage addons.
The recommended addon flow dodges the command line, which tells me it's targetting non coders. This makes sense from a whole team perspective - you don't want your tool to be inaccessible to artists and musicians who may not care to learn CLI basics.
But software engineering is all about dependencies and libraries. I want it to be easy to improve an addon that a game depends on (multiple games, probably) without fuss.
I've hacked this with symlinks before, but things broke when trying to get more users (or another of my machines) running the game. Then I added commands to make this 'easy' (just install java, clojure, and babashka, you artist, you!).
This led me to vendorize everything, which basically means don't .gitignore your addons, so your team members can download and run the game without fuss.
Lots of tradeoffs happening here, not sure the best solution yet.
For now, I'm working on all my games in a single project: a godot monorepo called dino. It's full of addons and games, and I can work on all of them in one place. The overhead then shifts to managing independent builds/exports/deploys, and so far that has been fairly smooth. We'll see where it breaks, but I think it's been excellent for my growth - I'm getting alot more done in less time, and getting to easily reuse and improve patterns as we go. That reuse/improve part of the cycle is important - most addons are not worth creating and isolating when you first have the idea, so giving them a chance to be consumed by multiple games shapes the public interface before I got sharing it elsewhere. Love me some monorepos!