What are monorepos?

We will discuss what monorepos are and the essential criteria for monorepo implementation

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

Table of Contents
  • |

Lesson Transcript

  • [00:00 - 00:13] In this lesson, we discuss what mono-repose are and what a good mono-repore means. So strictly speaking, a mono-repore is a single repository containing multiple distinct projects with well-defined relationships.

  • [00:14 - 00:23] So what are the essential criteria for mono-repore implementation? Mono-repore should not be just a location where all the code lives.

  • [00:24 - 00:40] It must effectively address the fundamental challenges inherent in managing numerous interdependent packages or projects. So here's a rundown of main requirements for an optimal workflow, source code sharing.

  • [00:41 - 00:50] Being able to easily share modules and libraries are important within a single mono-repore. Local dependency linking configuration.

  • [00:51 - 01:10] The mono-repore tooling ought to facilitate local dependency linking. This means that within the repository, the code of other packages should be accessible and loaded internally, while still maintaining version control and the ability to retrieve dependencies from a binary repository upon publishing.

  • [01:11 - 01:22] Dependency analysis. It should be able to identify the dependencies existing among various projects within the repository without needing additional configuration.

  • [01:23 - 01:38] Local computation caching. The ability to save and review task outputs as well as store files for future reference ensures that repetitive building and testing of identical output on the same machine becomes a thing of the past.

  • [01:39 - 01:48] Affected packages identification. The system should determine which projects stand to be impacted by changes within the repository.

  • [01:49 - 01:58] These entails identifying modified projects or those that rely on them, regardless of the level of dependency. Local task orchestration.

  • [01:59 - 02:13] Leveraging the repository's dependency structure, it should orchestrate tasks in the correct order as well as in parallel. For instance, integration tests should not be conducted until all requisite projects have been built beforehand.

  • [02:14 - 02:26] But integration tests can run in parallel. In this lesson, we learned what a mono-repore is and what constitutes as characteristics of a great mono-repore in detail.

  • [02:27 - 02:31] In the next module, we will look at how we can configure a PNPM workspace.

In this lesson, we discuss what mono-repose are and what a good mono-repore means. So strictly speaking, a mono-repore is a single repository containing multiple distinct projects with well-defined relationships. So what are the essential criteria for mono-repore implementation? Mono-repore should not be just a location where all the code lives. It must effectively address the fundamental challenges inherent in managing numerous interdependent packages or projects. So here's a rundown of main requirements for an optimal workflow, source code sharing. Being able to easily share modules and libraries are important within a single mono-repore. Local dependency linking configuration. The mono-repore tooling ought to facilitate local dependency linking. This means that within the repository, the code of other packages should be accessible and loaded internally, while still maintaining version control and the ability to retrieve dependencies from a binary repository upon publishing. Dependency analysis. It should be able to identify the dependencies existing among various projects within the repository without needing additional configuration. Local computation caching. The ability to save and review task outputs as well as store files for future reference ensures that repetitive building and testing of identical output on the same machine becomes a thing of the past. Affected packages identification. The system should determine which projects stand to be impacted by changes within the repository. These entails identifying modified projects or those that rely on them, regardless of the level of dependency. Local task orchestration. Leveraging the repository's dependency structure, it should orchestrate tasks in the correct order as well as in parallel. For instance, integration tests should not be conducted until all requisite projects have been built beforehand. But integration tests can run in parallel. In this lesson, we learned what a mono-repore is and what constitutes as characteristics of a great mono-repore in detail. In the next module, we will look at how we can configure a PNPM workspace.