One of the reasons for creating yarn in the first place was performance – it took too long to install dependencies in large projects with npm. There are even more features originated by npm that are also leveraged by yarn, such as publishing to npm registry. More shared concepts and features are dependency management, publishing, or using lock files to "freeze" dependency versions. ![]() ![]() As an example, both leverage the concept of package.json as container for dependency management, which was introduced by npm back in the days. Npm (marked by 1) and yarn (2) are both native package managers that have many features in common (3). The diagram’s purpose is just to give an impression how things are connected. By the way, do not take the proportions too seriously. It depicts three main players and how they correlate. Take a look at the following "set diagram". I want to shed some light on the clutter how npm, yarn, yarn workspaces, and lerna are involved in the topic of Mono-repos. Correlation between npm, yarn, yarn workspaces, and lerna lerna and yarn workspaces together improve the developer experience of managing multiple packages in a Mono-Repo. This results in faster code-test-debug cycles by sharing components locally. Thereby, these tools make it obsolete to manually create symlinks or use "low-level" npm link directly. The beauty behind these technologies is that they can find package dependencies by analyzing package.json files located at each project’s root folder. Managing these dependencies are implemented by symlinks.Īs we see later, lerna and yarn workspaces give us the ability to build libraries and apps in a single repo without forcing us to publish to npm or other registries. Packages might have dependency relations between each other. Therefore, every package contains its own package.json file due to the fact that every package is a full-fledged project on its own. These packages are "Mini-Repos" that can be versioned, built, and published independently. Tool Landscape for Mono-ReposĪ Mono-Repo hosts one or more projects or packages. To find out about differences along with pros and cons of Mono-Repos and Multi-Repos, I recommend Markus Oberlehner’s article about Monorepos in the Wild. Plus, there exist teams leveraging both approaches because the technology, which is part of the repository, is also a factor to have in mind for decision-making (e.g., every Java micro-service is part of an own git repo). There are teams that pursue a Multi-Repo approach and there are teams believing in a Multi-Repo maxim. In my current job, we constitute multiple teams where each team has its own repositories. Of course, a combination of both approaches is possible. In contrast, using multiple repositories with each repository housing only one project is called a Multi-Repo approach. Such projects are called workspaces or packages. In short, a so-called Mono-Repo is a (git) repository that houses multiple projects. ![]() A lot of articles were written or conference talks were given about this topic. Mono-Repo) has gained some traction for about one or two years. Tools like lerna and yarn workspaces have been a decisive factor with the result that managing your codebase in a single repo (a.k.a. What is a Mono-Repo? How does it Compare to Multi-Repo? Especially lerna and yarn workspaces can peacefully coexist in a project. It also makes sense to use these tools in combination. However, the goal of this article is all about Mono-Repos and how lerna, npm, and yarn ( workspaces) can help. I don’t want to assess in great detail what repository type is better in which circumstance. After a brief introduction to Mono-Repos and a comparison with Multi-Repos, I go into tools for establishing Mono-Repos. This post is my take on the topic of Mono-Repo.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |