<aside> 📦 A strategy for managing code for multiple projects in a single repository.
</aside>
Traditionally, a repository has served as a home for everything related to a single code project: the code, configuration files, assets, etc. that make up that project.
A repostory for a package published to npm
A repository’s output is typically deployed (in the case of an app) or published to a package manager like npm (in the case of a library, like react or lodash).
To read the project’s code, report a bug, request a feature, or make changes to the code, a user interacts with the project’s repository.
Interacting with a repository
This setup works great for a single, self-contained project! But what do we do if we also want to deploy a documentation site for the project or split a package into two related packages?
More repositories!
This setup works great for keeping each repository single-purpose, but if you think about your deployables and publishables as an ecosystem, it gets quite messy!
User input to multiple repositories