Heavy computation is done by the core Node.js and modules written in C++. It has been available for years but has become highly popular just recently. The Nx tool was created by the Nrwl team. The inactivy of Lerna during this past year has made it lag behind. The creator of Lerna has decided to hand over the project to Nrwl 🚀🚀. Update: there are has been a plot twist after this article was published. So what are our choices when building a JavaScript/TypeScript monorepo ecosystem? In this article, we will be checking the most popular tooling. Even if many still love and enjoy lerna it is time to move on. It could not compete with the performance of the most recent tooling. Why? The author would be eager to rewrite it than make amends. The project won’t be handed over although it is consistently hitting a bit more than 1.3M daily downloads. Consider adopting an alternative toolset for monorepo management. Important note: this project is not actively maintained. Although its creator voiced his burnout and intention to abandon the project it was not made official until April 2020. Lerna has been officially killed recently. Its goal was to enhance and make it scalable helping build, orchestrate, and publish your packages. However, they lack some features that were never intended to build. Tools like npm, yarn, and pnpm provide some native support for monorepo. One immediate benefit is that it empowers us to share configurations like ESLint, Prettier, TypeScript, … through different projects ensuring consistency. It is a great way to keep distinct projects with well-defined relationships. Otherwise, stick with the thing everyone is comfortable using.The monorepo approach is a great way to manage all the dependencies. To sum it all up, if you have a monorepo or performance issues with NPM, consider using an alternative option like PNPM or Yarn. I came across PNPM and it was instantly beneficial to me, so I stuck with it. That said, I don't feel like I can fairly evaluate the two because I don't have enough experience with Yarn Workspaces. Its approach to structuring the node_modules directory is of great benefit when managing several projects with package.json files in the same repository. PNPM, on the other hand, seems very much focused on monorepo support.
Yarn has a feature called Workspaces that is geared toward making Yarn work well for monorepos.
Yarn has significant performance improvements over NPM, and it's a more popular and accepted option when compared to PNPM.Īnd if your project is a monorepo, PNPM and Yarn are both good options. When NPM's performance becomes an issue, I'd likely first switch to Yarn. Generally speaking, I'd say no, not necessarily! There's a ton of value in using the ubiquitous option - which, unlike the word ubiquitous, is the one people best understand and are most comfortable using.īut there are two scenarios in which I'd welcome a change: Is it really a good idea to use an NPM alternative when the default (NPM) actually works fine, but is maybe a bit slow? And, like Yarn, it's much much faster than plain old NPM. It's like Yarn in that it is a command-line tool that helps you manage JavaScript project dependencies using the NPM registry. That may lead you to the question I asked when I first heard about PNPM: Is it just another NPM alternate? PNPM stands for Performant NPM, which means it stands for performant node package manager.
0 kommentar(er)
