WIP: Monorepo Tooling & Design Decisions

[alexwilson]

⚠️ This description is incomplete. ⚠️

To ease maintenance in an effort to progressively extract & replace functionality from an aging codebase, I moved towards a mono-repository.

So far this has been a boon, and these have proved to be useful design decisions:

• Lerna is both feature-complete & fairly stable, and offers wildcard-based module discovery.
• Builds, tests & deployments are parallelised via GitHub Actions.
• These parallelised workflows always run together ("monolithic build"). Note: This isn't necessarily a problem, aside from CI taking longer than it should do, and also surfaces problems quickly.
• Tooling like Dependabot is able to interact with independent subpackages without manual intervention.

However, there are still some workflow challenges I would like to address:

• Lerna is based around a package workflow, meaning that applications follow a library deployment lifecycle (e.g. publish).
• Secrets are shared & available to all workflows meaning that the blast-radius for changes is high.
• Infrastructure-as-code (eg Cloudformation) isn't co-located as it's incompatible with this workflow.
• More generally, codebases don't necessarily follow the same stack (eg I'd like to introduce Rust & WASM) and most tooling is language-opinionated.
• However, some codebases are likely to be similar: eg Workers should all follow the same blueprint.
• It would also be nice if IDEs were aware of the separation.
• Adding new tools to support the entire mono-repository (e.g. Storybook) is non-trivial and involves lots of dependency-wrangling.

A bigger outstanding question:
What is the "scope" of frontend, should this strive to contain all of my stack? (i.e. be platform?)