Project Structure and Management
When looking at the twelve factor app methodology, there are a few apparent inconsistencies with the trends in managing codebases right now. The twelve factor app states that we should only have a single repo, or it is then a "distrubuted system". However, many organization store their code in a "Monorepo" which contains multiple applications. When considering microservices and monorepos, the line between what should be factored out into it's own versioned dependency becomes increasingly blurry.
Mono-repo vs Mulit-repo
What is a Monorepo?
A Monorepo is a single, large repository to hold your entire organization's code. Inside the repo are "sub-repos" to break up the code into modules or another structure.
Advantages:
Configuration/Linting can be set for all projects
Packages can be installed for all projects, but projects can also have independent packages.
Testing across all packages becomes much easier.
Only one repo must be cloned, instead of many projects of organization.
Disadvantages:
More upfront work on tooling and automation.
Granting partial permissions more difficult.
What is a multi-repo?
A multi-repo is the more "traditional" structure of separate repos for each section of the codebase.
Advantages to this are:
Clear separation of concerns
Can set permissions on access to code more easily
Disadvantages:
Global configuration difficult
Making changes across the entire codebase (to an API for instance), becomes very difficult.
When to go with a Monorepo vs multi-repo
For many small teams, a Monorepo represents a premature optimization. Many libraries are still not setup with multiple packages in mind, and learning how to configure them the first time is not trivial. On the other side, a Monorepo that is too large poses an entirely different set of problems. Tracking issues across one giant repo makes it difficult to separate concerns, and one connected repo makes it hard for a team to have a space to own.
However, with tools such as Lerna and the general increase in popularity for Monorepos, managing them has become much simpler. Given that large tech companies often operate in a Monorepo, major open source libraries like Facebook's Jest and Yarn are working on first-class support to them. If you are starting with a new project and can benefit from the clear separation of different packages (ie separate component library), then I think Monorepos make a lot of sense. Being able to have consistent tooling, CI/CD setup, and update packages and API's is a major advantage.
Packaging/ Dependency Tools
Yarn
Workspaces
Takes in multiple
package.json
files from subfolders. In then combines all of these and pulls out the packages needed only once. Each individual "package" is then it's own workspace which can have dependencies of other workspaces.
NPM
The original popular package manager, NPM
Also, they've recently been firing many of their senior staff which is never a good sign.
Lerna
Lerna tries to make managing multi package repositories (mono-repos) more manageable. It has features to accomplish this, but the two main concepts are bootstrap
and publish
.
bootstrap: links dependencies in the monorepo together.
publish: publishes updated changes to individual packages inside the repo.