Open
Description
⚠️ 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?)