Another tool to check your npm dependencies - wtfwith

Have you ever wondered how many versions of the same library your client or server assembly is dragging on? At one point, it became interesting to me. Offhand finding a ready-made tool for this did not work, and looking through the eyes of package-lock is too tiring. As we know, in any incomprehensible situation you need to write your npm package, so I did just that ... Further in the post I will consider the result of the analysis of a live project and draw a couple of controversial conclusions.

Well, you can’t do without this classic picture:

How does it work

In general, no rocket science - we take package.json and package-lock.json and go through all the dependencies that are there, collecting identical modules or fork modules. Forks, of course, have to be written with your hands, so now only lodash and undescore are listed in them. But you can always help and expand this list.

How to use

The module is published on npm, it is easiest to run using npx , although no one bothers you to install it locally or even globally. Next I will consider the option of running through npx. For example, I’ll take one of my old projects, which is essentially a monolith on a node (this was before the microservice boom, and then sawing it was lazy and impractical).

1. npx wtfwith moduleName(for example, npm wtfwith lodash) - we check the number of occurrences of a certain module, displays the results if there are more than two. The result can be, for example, such:


2. npx wtfwith everything(you can simply omit the argument and write “npx wtfwith”, but this is depressing) - it checks generally all the dependencies, which are more than two versions. Maybe, for example, this result:


3. You can also specify an option --dev- in case, for example, if you are building a bundle of dependency maids. Although it’s better to use front-end tools for analyzing bundles. I will not show an example of use, the command looks like npx wtfwith everything --dev, and you can imagine about what the hell goes there.

Real examples

Of course, it would be interesting to analyze several popular packages, which I did.

1. express - surprisingly, nothing interesting was found.

2. gulp - all sorts of little things were found:



3. npm is a pretty funny result:

At least it’s funny that npm is clearly trying to minimize the use of lodas, but one of its dependencies is completely overwhelming it ...

Todo

The project was written overnight on the knee, so there are a number of things that are not implemented there:

1. There is no work with the shrinkwrap file - but this is not very necessary, you can just generate package-lock for verification;
2. Only node 6+ is supported. Also not very critical, because there is nvm;
3. The larn file from yarn is not supported. Again not too critical;
4. Surely there are a number of bugs and inaccuracies.

In general, if the tool is relevant to you, then pull requests are welcome.

conclusions

The results do not look very nice, but to be honest, I expected more hell. Apparently, many people still use tools for analyzing updates and dependency protection.

From the controversial recommendations:

1. I would not recommend for deliberately back-end modules to tighten dependencies like lodash in pieces - anyway, someone will surely drag out the full version of the library. Well, do not forget about semantic versioning - of course, without exact version restrictions everything may break at some point, but this should be solved by fixing dependencies in package-lock and interaction between developers, and not by exact restrictions. That is, if you find breaking change in some kind of dependence, it would be nice to go to the author of the package and say that it is wrong - this will save others a lot of effort and terabytes of disk space.

Although here the author respected by me ioredis does exactly the opposite .

2. It is worth periodically running through your dependencies and looking at what is suspicious in them, and then unsubscribing issues or doing pull requests to problem modules.

If the problem of updating dependencies is close to you, then in the end I can advise several useful tools:

1. npm-check-updates - we quickly look at package version updates, we quickly install them. Just be careful!
2. snyk - checking the security of packages, I already wrote about it a little earlier .
3. node security project - another tool for checking dependency security, which can be considered native to the ecosystem, because it was recently acquired by npm.
4. In case you are working with the front, you are probably using something like webpack-bundle-analyzer, which will tell you what exactly you got as a result. But I don’t work with the front, so I can’t give any clear recommendations.
5. It is also useful to have all sorts of badges and CI integrations that will clearly show and notify you if something is out of date or has become unsafe. I will not give examples of badges, there are a lot of them, and you can look at a part on shields.io . There are many integrations too, and if you have an open source project, then travis-ci can run almost any kind of test.

Such posts appear periodically, but time goes by - so tell us what useful checks and tools you use in your projects now.