Another tool to check your npm dependencies is wtfwith

Have you ever wondered how many versions of the same library your client or server builds drag out? Me here at some point it became interesting. Offhand to find a ready-made tool for this did not work, and looking at the package-lock eyes is too exhausting. 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 review the result of the analysis of the live project and make a couple of controversial conclusions.

Well, you can not do without this classic image:

How does it work

In general, no rocket science - we take package.json and package-lock.json and run through all the dependencies that are there, collecting identical modules or forks. Forks, of course, you have to register with your hands, so now they only indicate lodash and undescore. 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. I will continue to consider the option of running via npx. For example, I will take one of my old projects, which is essentially a monolith on the node (this was before the microservice boom, and then it was too lazy to cut it and it was inexpedient).

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


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


3. You can also specify the option --dev - if you, for example, collect a bundle of dependency --dev . Although for this it is better to use front-line tools for analyzing bundles. I will not show an example of use, the command looks like npx wtfwith everything --dev , and you can imagine what the hell is coming out of.

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 - there were all sorts of little things:



3. npm is a pretty funny result:

At the very least, it’s funny that npm is obviously trying to minimize the use of lodash, but one of its dependencies is dragging it all down ...

Todo

The project was written in the evening on the knee, so there are some 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 simply generate a package-lock for verification;
2. Only node 6+ is supported. Also not very critical, because there is nvm;
3. Lock 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.

findings

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

From controversial recommendations:

1. I would not recommend for knowingly backing modules to tighten dependencies like lodash with chunks - anyway, someone will surely pull the full version of the library to itself. Well, don't forget about semantic versioning - of course, without exact version restrictions everything can break at some point, but this should be solved by fixing dependencies in package-lock and interaction between developers, and not exact restrictions. That is, if you find yourself breaking a change in some kind of addiction, then it would be good to go to the author of the package and say that he is wrong - this will save others a lot of effort and terabytes of disk space.

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

2. It is necessary to periodically run over your dependencies and look at what is suspicious in them, and then unsubscribe issues or make pull requests to problem modules.

If you are close to the problem of updating dependencies, then finally I can advise a few useful tools:

1. npm-check-updates - we quickly see updates for package versions, quickly install them. Just be careful!
2. snyk - check security packages, about him I wrote a little earlier .
3. node security project is another dependency security tool that can be considered native to the ecosystem because it was recently acquired by npm.
4. In case you are working with the front, then you probably use something like webpack-bundle-analyzer, which will tell you what exactly you got as a result. But I do not work with the front, so I cannot give any intelligible recommendations here.
5. It is also useful to have all sorts of badges and CI integration, which you will visually show and notify if something is outdated or has become unsafe. I will not give examples of badges, there are plenty of them, and you can look at a part of shields.io . There are a lot of integrations too, and if you have a opensource project, then travis-ci can run almost any checks.

Periodically, such posts appear, but time passes — so tell us what useful checks and tools you use in your projects now.