The multi-repo strategy employs numerous repositories to house different libraries or services of a corporation's projects. It contains every set of transferable code (such as a microservice) underneath its repositories.
A repo is a storehouse for all the changes and files from a project, encouraging developers to “version control” the project assets throughout its development stage.
GitHub, Bitbucket, and GitLab are version control mechanisms offering repository management. There are two main approaches for hosting and managing codebase, i.e., Git: the mono-repo approach and the multi repo approach.
A Mono-repos (mono repository) is a single repository that stores code and assets for every project. Multi-repos, on the other hand, refers to arranging projects in their separate repositories.
Google, Facebook (Meta), Twitter, Microsoft, and Uber, some of the most advanced technology companies globally, use monorepos.
Why MonoRepos are cool?
Benefits of monorepos
The monorepo approach has several benefits:
- Easy visibility of code. Monorepo brings everything in a single repository and provides a great deal of flexibility to build. Teams can look at each other’s code and assets and even help resolve bugs or improve code quality with cross-team contributions.
- Easy sharing of code. If standard models, shared libraries, and helper code are all stowed in a single repository, teams can transmit them among many microservices.
- Improved cooperation. A monorepo terminates barriers and silos between teams, making it more comfortable developing and maintaining collections or sets of microservices that can work well together.
- Standardization. It is easier to impose branch policies to keep your main branch clean, limit access to specific branches, implement naming guidelines, possess code reviewers, and implement best practices. Branch policies keep work in progress separated from the completed work.
- Easy Discover of code. In a monorepo, you have a single picture of the whole code. You can see the entire repository’s status, screen all the branches, and keep track of changes.
- Management of release of code. There is less chance of losing any information when code is deployed in the system. An automated build and deploy pipeline no longer masks or hides deployment knowledge within each team.
- More manageable refactoring. Direct access to all microservices drives to easily refactor the code in a monorepo. Pushing the source code between folders and subfolders is easier than moving the source code between multiple repositories.
How Do Major Organizations Manage Code in Monorepos?
When working on a large codebase, we deal with various version control repositories. This would not be an issue if each project were stored in unified repositories.
However, because huge businesses like Facebook recycle a lot of code, there's a lot of interdependence across projects. So, for example, you utilize library B if project A is dependent on it. Worse, if Project A relies on C and D, both of which utilize library B, you must ensure that the versions of B used by C and D are comparable. As you may expect, this is a complicated situation.
Facebook follows the concept of establishing big, concise repositories. You can make atomic reforming throughout the whole codebase without worrying about versioning concerns because there is just one repository. A branch can be created by those who require a stable version of the source.
A monorepo is a software development process where a single version control repository has source code for multiple projects, libraries, and applications irrespective of their programming language. Monorepo strategy organizations often use a standard build tool (like Bazel, Pants, Buck) to manage the source code.
Monorepos For Full-Stack Development
Implementing both the front and back end of a web app is called full-stack development. Full-stack web designers can construct fully functional online apps, web pages' front-ends, back-ends, databases, and troubleshooting.
Benefits Of Monorepos for Full-Stack Development
All configurations and tests are kept in one place.
Because everything is contained in a single repository, the unit, e2e, and integration tests are all the same. The CI will be competent enough to run all tests without further setup.
With atomic commits, you can easily modify global functionality.
You can produce one pull request that includes all additions pertinent to the functionality you're working on, rather than writing a pull request for each repo and starting to figure out how to compose your adjustments in the appropriate order.
Simplified package publishing.
You can use a command line to introduce new functionality within a product reliant on another product with common code. This procedure requires some extra setups, detailed later in this article's tooling review section. Lerna, Yarn Workspaces, and Bazel are just a few technologies available right now.
It's a lot easier to handle your dependencies now.
Just one package.json. You don't have to re-install them in each repo. one version of every dependency means there are no versioning conflicts and no dependency hell.
Use shared packages to recycle code while keeping them separate.
Monorepo lets you utilize packages created by other programs while preserving them separately. You can use references to a secluded package and consume it from a single location. Local symlinks can be used to access the local version; this functionality can be added using bash scripts or extra tools such as Lerna or Yarn.
Tools Of Trade
The number of tools for operating Monrepos is continuously increasing, and it's possible to become lost in the multitude of Monorepos installation systems possible right now. Using this repo, you may always be aware of the most popular solutions. But, for the time being, consider some of the most widely used solutions today:
- Yarn is a JavaScript-dependent managing tool that uses workspaces to enable Monorepos.
- Lerna is a Yarn-based tool for organizing multi-package JavaScript projects.
The majority of the tools follow a similar pattern; however, there are notable differences.
Lerna is a library that manages multi-repository structures inside a single repository by splitting subsets of the repository into own “sub” repositories. A repository organized in this way is called a mono-repo.
Lerna is primarily used in bigger projects that can become challenging to maintain over time. It modularizes the code into smaller manageable repositories and abstracts shareable code that can be used across these sub repos.
It manages tasks like versioning, code deploying, tooling, etc., paving a smooth path for the developers without thinking of the baggage that comes with a mono-repo architecture.
Yarn began as a reliance repository for NPM packages and wasn't designed with Monorepos in mind. However, Yarn developers added functionality called Workspaces in version 1.0. It wasn't very stable when it was first released but became usable for projects after a while.
Workspace is a bundle with its package.json file and its own set of development rules (for example, if you utilize TypeScript in Project, separate tsconfig.json ). You may get by without using Workspaces and still have a similar setup, but this resource greatly simplifies the procedure of installing or upgrading repositories per package.
Setting Up A MONOREPO For MERN Stack App
There are several structural advantages to a Menorepo:
- Visibility of its code assets
- Centralized and integrated versioning
- Code sharing and reuse
- Dependency management
- Atomic modifications that stay in control
- Capability to accomplish structural changes
MonoRepo for Mern Stack
Using Yarn workspace to setup monorepo for a MERN stack project.
The Structure would be as below:
root-folder >
- API-folder
- app-folder
In the root folder, make a folder name packages, and inside it, make your client and API folders.
An API client is a group of tools and protocols that operate from an application on a computer. They help bypass operations when developing a web application rather than reinvent the wheel every time. Using a client API is an excellent way to quicken up the development process. It helps developers and statisticians focus on critical issues such as writing codes and programs respective to the project. API should possibly have repositories for database schemas and documentation etc.
Client Application signifies any application, plug-in, helper, component, or other executable code that operates on the user’s computer; examples of Client Applications contain those that provide instant messaging, chat, email, data, file viewing, media playing, file sharing, games, internet navigation, search and other services.
In the package.json file, change the name of client and API as @[rootfolder_name]/client and @[rootfolder_name]/API respectively.
Below is the Client package.json of both folders and the folder name is a video library
Below is the API package.json of both folders and the folder name is a video library
Install a package called concurrently in the root folder.
Concurrently is a package that can execute numerous npm scripts simultaneously.
Run React and Node servers simultaneously.
Next add Add "workspaces" :
["packages/*"] and Add "engines": { "node": "14.15.0" } in package.json of the root folder
package.json file will look as below: That's all; you're ready to go! Your Monorepo is now up and running.
Top Cities where Knowledgehut Conduct Full Stack Developer Bootcamp Course
Simplifying the Dev Process with Monorepos
Monorepos is typically a unified repository that houses numerous related and unrelated projects. Monstrous monorepos, which contain multiple unconnected programs and thousands of chains of code, and monorepos, which include linked elements of a given package, are the two types of monorepos in this meaning.
We can list centralized management because a single repository house overlapping projects, visibility because everything is accessible to all collaborators, interconnection. The design phase is the center console, comprehensiveness because any program could be built using the repository's tools, and uniformity because monorepos engineers typically use the same set of tools as multirepos engineers.
There is simple dependency since library versioning is simple, simpler structure since programs are structured more consistently, easier reworking because modular repositories support modular code, and enhanced general work culture are the key benefits. Monorepos, after all, promotes team cohesion, tooling (since a single common hierarchy makes it easier to build tools that work across different projects), and improved developer coordination (because developers can easily use a single shared hierarchy).
