Skip to main content
M1nxy's Blog

Better alternatives to npm

A short rant about package managers

NPM Kinda sucks

Ok not really but there are better alternatives that solve many of my gripes with npm such as oversized node_modules in every project folder, slow package resolve and download times while serving as 1:1 replacements.

Both tools I'm going to talk about were built with the node.js runtime in mind and are included by default in corepack. This is also a reason why I omitted bun, by default it uses It’s own runtime and I would not consider it 100% a 1:1 replacement for npm. They also both use the npm package registry so you won't be missing anything. They also feature qol additions to npm such as command aliasing and better-formatted outputs.

One downside of both tools is their independant lockfiles, they are incompatible with each other and require purging node_modules to switch between tools. This poses a potential problem in any project that tracks the lockfile and targets specific versions of packages. As far as I know there is no trivially solution for this issue so some effort must be put in to migration in these cases.

Yarn berry

Yarn berry is a modern nodejs package manager written from the ground up with performance and extensibility in mind. It supports many of the same features as pnpm while allowing extensions through it’s plugin api. Like pnpm it features parallel downloading and similarly saves the user disk space via hard linking from a centralised cache; this has the added advantage of resolving packages faster.

It also has support for workspaces (monorepo), it does this via adding the workspace to the package.json referencing other submodules with the workspace: protocol. These links are then resolved when publishing via yarn npm publish as can be seen here.

PNPM ⭐️

pnpm is what I personally use and would recommend to anyone considering moving away from npm. It is much faster than npm, supporting parallel downloads and hard linking packages from a cache in a way similar to that of yarn. It also has sensible defaults and fallback options to certain commands making them much more flexible and easier to work with. For example pnpm start will first look for a start property in your package file and if not found will fallback to node server.js only failing if neither are present.

Where it differs from yarn is it’s default peer dependency installs and greater flexibility with workspaces. It achieves the latter via a file in the root of the workspace that allows pnpm to resolve dependencies to local packages by targeting them either with the either:

  • The workspace: protocol (same as yarn)
  • A defined alias
  • The relative path of the module

I prefer the extra choice pnpm gives you in this regard and all options resolve to normal looking versions in a way similar to yarn. (see here)

Conclusion

Unless you are working on legacy node projects or need to track your lock-file and work with a team committed to using npm, your migration is long overdue. Although either tool is a valid choice, and it mostly boils down to personal preference, if you are planning on using a monorepo or already are using one I would strongly consider pnpm or tools built ontop of it such as bit.