This content originally appeared on Bits and Pieces - Medium and was authored by Jonathan Saring
For years every JS developer worked daily with packages installed using NPM client, often from the NPM registry or an organization’s private registry.
In the past couple of years, the world changed in many ways. The decline of NPM gave rise to tools like Yarn, while registries diverse to the point even GitHub provides one. At the same time, the way we build modern applications becomes ever more modular, stressing the need to share and reuse code.
In this short post, I’ll briefly outline the existing possibilities for systematically turning components of your system into versioned packages which you can share and consume in multiple projects. Not all of these are necessarily package managers per-se, but all provide a great solution to that problem.
Please do feel free to comment and add anything I might have missed. In my next post, I’ll review some of the best private registry alternatives out there. But for now, let’s move on to explore some of these NPM alternatives.
1. Bit
Bit is not a package manager. With Bit, you don’t need to work hard to publish packages anymore. With Bit, every app is by definition a multi-package monorepo, and every small part of it will be published as a package.
Bit makes it incredibly easy and efficient at any scale.
With Bit, you can build your app while every small part of it automatically becomes versioned, packaged, and ready to publish during development. Then, you ‘bit export’ (push/publish) the component to the secure bit.dev platform (works with JFrog etc) and installs them in other projects using NPM or Yarn. Or, you can choose to publish it to any registry of your choice.
If you do export to the bit.dev platform (it works with Artifactory etc), you will enjoy many features from organized collections to search, visual docs, previews, teams, and automated updates that propagate incrementally.
Bit is commonly used in the fronted world for components (due to how easy it makes it to publish many small packages), but works just as well — and even better!- for node modules and any reusable JS logic or code unit.
Here are some of the key features that turn Bit into the most powerful ‘reuse-js-components/modules’ solution in existence today:
- Unlimited granularity level — Bit makes it easy to publish dozens or hundreds of packages by automating the boiler-plating and management overhead that comes with it. Just publish every code you’d like to reuse, it’s easy, and you don’t need to split your repos or anything.
Building a React Component Library — The Right Way
- Every repo is a monorepo — Bit’s workspace turns every repo into a monorepo, and help you publish and manage many components from the same repository without the overhead of managing a monorepo.
- Automated configs and packaging — Bit abstracts away the pain and overhead of having to set up multiple files for every package. Instead, it automatically creates, defines, and updates all configs for you.
- Standardization with templates — Develop new packages in the repo with ‘bit create’ — a command that summons custom reusable templates for creating packages in a standard way (best practices included). And, it includes visual MDX-based docs that are half self-generated.
- Automated versioning and dependency management — Bit automatically defines and updates all the dependencies of every package you create in the workspace, and across different projects.
How does it work?
With Bit every independent component is its own sub-repository. It includes its source-code, a dependency graph that contains packages as well as other independent components, dev env config, and various built artifacts. One of these artifacts is a distributable NPM package. At any moment, you can just publish your components, and install them using NPM/Yarn anywhere.
Try it out ->
Bit: The platform for the modular web
2. Yarn
At this point Yarn really does not need an introduction. born in FaceBook and Google, when Yarn was first introduced with its blazing speed and revolutionary lock file, it was so much better than NPM in many ways, that it quickly took a large bite of the ecosystem. Since NPM 5, very few differences remain between the two prominent package managers.
In terms of performance, most agree that Yarn enjoys enhanced performance by a significant range. Yarn’s output is considered cleaner and less verbose than npm. In Yarn 2, there is a small revolution, as ‘node_modules’ will no longer be supported by default. And since Yarn only needs to generate a single text file instead of tens of thousands, installs become more instantaneous, stable, and performant. Read more about Yarn-specific features here.
For me, the real advantage of Yarn lies in Yarn Workspaces. Workspaces aim to make working with mono repo easy, solving one of the main use cases for yarn link in a declarative way. Multiple projects (packages) can live together in the same repository and to cross-reference each other— applying modification to each project’s source code to other projects.
3. PNPM
So common really, why should anyone publish packages with a tool that is not Bit, Yarn, or NPM (preferably publish with Bit, install with whatever)?
Here PNPM came into the picture. While still not widely adopted like the previous tools,
Pnpm is compatible with npm but is more disk-space efficient. When you install a package, it keeps it in a global store on your machine, then creates a hard link from it instead of copying. For each version of a module, there is only one copy kept on disk. And it uses symlinks to reference packages. It introduces the “content-addressable storage” system which can detect differences between files for performance and workflow optimization by not duplicating unchanged files on version bumps. Incremental file duplications of sorts if you will. And, it does not let package access and mess around with dependencies other than their own.
4. Turbo
Turbo is not a package manager you can use anywhere today other than on StackBlitz. So why would you even want to know about it?
Because technology and design-wise, it’s a game-changer in terms of performance. I was built because NPM does not wok well in the browser (you can read how codesandbox did it here). Making the module ecosystem work efficiently in the browser requires some new thinking in more than one way.
Here are a few examples.
Turbo claims to install package 5 times faster than Yarn and NPM. It greatly reduces the size of node_modules (but its still there), and works entirely in your browser — making it a technology worth keeping an eye on.
Turbo uses a resolution algorithm to aggressively resolve common package versions and reduce payload sizes. A serverless version of the resolver has access to NPM’s entire dataset in-memory and resolves any package.json in <85ms, according to authors.
It’s worth noting that the ecosystem has come a long way, and new tools like Deno (Watch ->) and Bit (Try ->) will change the wey we build with modular JavaScript and in the browser — taking us a leap further into the future.
Introducing Turbo: 5x faster than Yarn & NPM, and runs natively in-browser ?
That’s it for now. Thanks for reading!
Learn more
- Building a React Component Library — The Right Way
- 4 Bit Use-Cases: Build Micro Frontends and Design Systems
- Independent Components: The Web’s New Building Blocks
4 NPM Alternatives: Best JS Package Managers and Publishing Tools was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Jonathan Saring
Jonathan Saring | Sciencx (2021-06-01T18:00:09+00:00) 4 NPM Alternatives: Best JS Package Managers and Publishing Tools. Retrieved from https://www.scien.cx/2021/06/01/4-npm-alternatives-best-js-package-managers-and-publishing-tools/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.