Npm and Yarn
The biggest after NPM is yarn. Which was brought by facebook and tries to deal with both package manager and infrastructure issues npm has. I’ve been using both of them daily and still can’t pick which one I like more.
+ a bit faster
Yarn has improved cache, both on the client and in infra level. That means it’s faster than npm. There were quite a few improvements on npm recently and it caught up. But now and then yarn just feels faster.
+ nicer running of commands, no need for
Npm package manager understands some commands without
test. But even after a millionth time, I forget that it doesn’t understand
star:dev that can be annoying and waste a few seconds of my life almost every
Where is in yarn, it’s understanding what’s in your
packages.json. Also if
you need to pass extra command-line arguments in npm you need to add a double
dash for it to work. Where is in yarn it’s cool as it is. Definitely less
friction and less time wasted there.
+ workspaces are better than lerna
Lerna is a tool to manage mono-repos. It tries to do it’s best to save the space and all with workspaces, but it’s not a package manager. So yarn just does it a little bit better, since it’s purpose is to deal with packages and the best part is that it can integrate with Lerna.
- problems with linking of the packages, at least with typescript
Because of the whole typescript type resolution, its compiler can get confused when linking packages with yarn. We need more maturity in both projects for it to not hit the edge cases as often. Or maybe I just need to stop doing weird stuff. ¯_(ツ)_/¯
- private registries can be a pain (with lerna)
npm ecosystem is mature enough to be quite stable, especially if you use their registry and all. But when you try to use some open-source registry it can get a bit tricky. There were some issues with yarn which require extra settings here and there. But the moment you add more tools things just get ugly. And the underlying issue can be in either of the tools. e.g. lerna maintainers not fixing yarn related issue because, well, it’s yarn’s optimizations. Similar to the previous point about workspaces, some less often use cases still brake.
Npm has taken out bower in the early days and gained the biggest market share. That means that most of the stuff will just work with npm when it comes to working with node.
+ private registries more standard
Even the open-source versions of the registry are built around the architecture of the npm. Using pouch db and all. This means integrating it with private registry will be slightly easier and more streamlined experience.
- can be slower
That’s one of the reasons other package managers exist. While this can be improved with private registries and caching it still has to make sacrifices here and there to be more universal.
- issues with installs from repositories, double install needed
I don’t know if it was an issue with a specific version or setup issue. But
when using private packages which are pulled from repositories, now and then
the state of the app would get out of sync. And to fix it you’d need to run
npm install twice. Have experienced that myself and probably anyone who has
ever used packages like that had that issue.
- lack of workspaces (sort of can be done with lerna)
Quite a few projects move to mono-repo setup for development and it makes sense. Especially if you ship your code as packages. While also simplifying the pr and testing process. But this means that some additional tooling is needed to deal with that because we need to deal with shared dependencies. You can achieve that with some of the tools, but compared to yarn it’s something you have to add rather than something you get out of the box.
So which one?
Pick one and use it. No matter which one you pick you’ll have to sacrifice something. Both of the tools are right for the job. But in general.
- Need more stable tool with more integration, pick npm.
- You can spend some time here and there for integrations, but want to gain more speed? Pick yarn.