![]() ![]() PnP is a new and innovative installation strategy for Node, developed in contrast to the established (and sole) Common,js require workflow that tackles many of its inefficiencies. You can read about Yarn Berry’s motivation to get rid of node_modules, but the reasons are similar to pnpm’s. Yarn Berry tried to ditch node_modules completely, using a Plug’n’Play approach. In such situations, hoisting can lead to phantom dependencies and doppelgangers. Jonathan Creamer gives a detailed view of what can go wrong in a monorepo project where the hoisting algorithm fails and causes production errors. Hoisting can lead to serious and difficult-to-detect errors, especially in large projects. The following image shows how this works: The differences between npm v2 and npm v3’s node_module algorithms The reason for lifting everything to one folder level is to reduce the redundancy that nesting causes. Simply put, hoisting flattens the node_modules folder in such a way that every dependency, even the dependencies of dependencies, ends up on the root level of node_modules. ![]() This same dependency resolution algorithm was also used by Yarn Classic in the beginning. The root problem of this flat node_modules layout is a concept called hoisting, which was introduced by npm in v3. The flattening algorithm is a time-consuming I/O process.Modules can (accidentally) access packages they don’t depend on, which can lead to bugs.The traditional dependency resolution strategy to flatten node_modules folders leads to several different issues: The problem with the traditional node_modules approach Traditional strategies have reached their limits in terms of performance and disk-space efficiency. The reason for this is that innovative resolution approaches are required to cope with the requirements of modern software projects, which increasingly make use of large amounts of dependencies. These modern package managers try to part ways with traditional approaches to process and store dependencies. When using the default configuration, pnpm and Yarn Berry do not use the same dependency resolution algorithms as npm and Yarn Classic, which involves flattening node_modules folders. A separate project to demonstrate different dependency resolution strategiesĪlternative dependency resolution strategies.A monorepo project to demonstrate workspace features.Therefore, I created two companion projects on GitHub to provide examples: This article covers several package manager features. What all these innovations mean for the future.Adding monorepo support with workspaces.Debugging issues with dependencies in Yarn Berry PnP.The problem with the traditional node_modules approach.Alternative dependency resolution strategies.We’ll cover the following things, comparing implementation options where applicable: The goal of this article is to convey how Yarn and pnpm have focused their efforts more closely on enabling developers to build monorepos through workspaces, and providing more advanced approaches to improve security and performance. While the focus in the previous article was on comparing core concepts and structures, this article will cover the advanced features of modern package managers, including monorepos, through workspaces. I’ve written in a previous article about the topic of dependency resolution strategies among npm, Yarn, and pnpm. This article aims to leave you with an impression of where package managers are headed in the future to support developers’ needs - such as by enabling developers to manage large monorepo projects with adequate performance and good DX. Advanced package manager features for npm, Yarn, and pnpm My fire for web development still blazes. Sebastian Weber Follow Frontend developer from Germany. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |