NPM is the most popular and primary package manager for Node.js. In fact, we can even say that every developer when they start learning nodejs, they have to also learn about npm package manager. They start with npm and maybe gradually switch to other better package managers like Yarn or Pnpm. Only after using npm for some time, do they understand that it is painful to work on npm and how much time it consumes.
Though npm is very popular, there are several downsides are drawbacks to the npm package manager. Every developer should be aware of this and mostly go for the alternative. There would be some offices that wouldn't support using other package managers. Maybe in that case they can stick to npm itself. But otherwise, yarn or pnpm is the best alternative. Personally, I prefer using pnpm.
I have had some issues with the NPM package manager where there would be dependency issues. Some packages might require a lower version of a package and another package might require a higher version of the package. This sometimes leads to conflicts and even when we are upgrading the packages, one of the dependencies we use in the project might need an upgraded version of another package, and another dependency might need a lower version of the package. When this happens, I usually pick an alternative package and keep going with the development. But it is a painful thing to address during development.
Security risks and issues with the package
When we are using npm packages, we cannot be certain that all the packages we see there can be clean and good to use. There will always be some bad packages with malicious code that can act like malware. I understand that all the package managers and maybe even the package managers in other programming languages can also have this problem. But internally there are some security measures taken by the package managers to filter out all those vulnerabilities.
We had a scenario once where there was no issue with the package in the package manager and it passed the security checks. But the code was still malfunctioning. Upon investigation, the Securities team found out that there was one package that was misspelled by another project and that the exact same code as the expected package and at the same time some additional code to track data. These are some simple security issues that can happen even if we misspell the package by mistake.
There can also be security issues with packages that are not being maintained. We might have used a package for a long time and it would have worked well. But what if there were no upgrades made to that package and the code is very old? This can become a headache for the developers. The reason is that this would lead to a bug in our own project. Working with a package that is not maintained is also another security risk and also painful for the developers.
Slow installation time
I have worked on bigger projects that have thousands of dependencies. When we try to do an npm install it can take more time than expected. I usually have --verbose set in the config to see what is happening in the logs. It helps to see the logs in a more detailed manner. Sometimes it may not be the package size that would cause slow installation but it can also be the internet connection.
Sometimes the companies use mirrors for npm package managers and are mosly self-hosted. That can be a little faster but if it is the internet and if they have to bypass proxy settings to get the data from the internet, things can be a little slow. I have seen projects that can take several minutes to complete npm install which can be a pain for the developers.
Due to the package size and the same package being used in multiple projects inside the dependencies, there is a high possibility that the node_modules folder can grow big in size. Imagine we are working on multiple projects and each project has a node_modules folder with 1 GB size or even more. That can also get painful to manage. In such cases, pnpm does things better. They also aid in faster installation and at the same time the node_modules folder size is also very less comparatively because they reuse the packages internally creating only one copy of a package that is required by multiple dependencies.
If you like what I'm doing on Hive, you can vote me as a witness with the links below.
 |
 |
 |
 |
 |
 |