Selecting Dependencies for a Project
Every web developer has come across this puzzle: which dependency to choose? Why do we choose jQuery, not Prototype, or Prototype, and not Mootools, or prefer Vue instead of React, or prefer Angular instead of Ember, or Lodash, rather than Underscore, and so we get an unlimited number of combinations.
I myself make a decision so quickly that it may seem unconscious. However, this is not so, and I decided it was time to describe some of my work processes, at least in order to adjust or revise them over time.
Types of Dependencies
When I select new dependencies, I rush between two fires. Either I need a framework-level project, or a ready-made solution (plug-in, library, or something similar). The selection process is also influenced by specific factors.
Below is a list of questions according to which I prioritize when considering any dependencies for a project.
1. Is the project being actively developed?
The answer to this question is especially important for large projects, since usually more than one person works on the code in them. A visit to an idle repository is far from a reason to abandon the technology, but I need to understand the technical potential of the new dependency.
Here are two aspects to which I pay a lot of attention:
- Recent commit activity – a quick look at the project’s main page on github usually helps here.
- The age of any open pull requsts – long hanging pull requests can indicate that no one has been involved in the project for a long time (I myself did this with Nodemon)
2. Is the project used?
Popularity is not a decisive factor for me, but the more software is used, the more bugs will be found in it.
In this question, I pay attention to:
- The total number of issue — a large number of open issue — is not always bad;
- Number of closed issue;
- The rate at which issue closes.
The speed with which the issue closes is not a particularly important factor for me, especially in a project where there are a lot of them. For me, having their discussion is more important.
3. Dependency Depth
There is a joke in the Node and npm community that the heaviest object in the universe is neither the Sun, nor a neutron star, nor a black hole – it’s node_modules.
We, as web developers, take a huge risk, and thank God that Deno appeared recently, who is trying to solve this problem with stdlib, which prevents the growth of the dependency graph.
Therefore, it’s important not the number of dependencies (which you can see on sites like npmjs), but their depth. It’s strange that I saw it only at Snyk.io, i.e. dependencies nodemon.
4. Availability of examples
As for the client-side libraries, I need interactive examples of working code and a sufficient amount of code in general to be able to recreate the demo myself.
So right away you can get the answer to the question: “Will this project do what I want from it.”
5. Documentation and complexity
The second most important, in addition to working code, is documentation for me. For small projects, I expect to see code examples in README. In larger projects, I hope for a few pages of documentation.
When I look at the documentation, I look for examples with which to start and ask myself: does the assembly of this project require additional tools?
Many of the projects that I came across in the documentation also contain assumptions about the presence of any knowledge, and the number of such assumptions increases the degree of complexity, especially if I am not familiar with the systems in question in the project.
For example, from experience, almost every Python project involves knowing how to install a dependency, and I do not fall into this category.
6. Version numbers
If the project does not use semver, this is usually already a red flag, since a very large amount of information can be found in the version number.
Recall that in semver major versions are indicators of critical changes, minor versions are changes in functions, and patch versions are bug fixes.
There is a certain nebula around the documentation and refactoring (when the external API works the same way, and the internal implementation is different, and you release, but this does not correspond to any changes in semver).
Nevertheless, a large major version number implies a high frequency of critical changes, which may indicate possible problems with the support of my project.
A large minor number (for example, the Snyk command-line tool, now version 1.323.0) involves many functions, and possibly a new release for each function.
A large version of the patch version, it seems to me, implies stability and constant support for the project.
7. Age
In real life, this would be ageism, but in the world of programmers, the age of a project can say a lot.
The “old age” of the project speaks of its maturity or may serve as a peculiar sign of abandonment. But what is old age? If Node turned 11 years old in 2020, then probably all projects whose age has exceeded 10 years can be considered old.
I usually avoid very young projects (a few months old).
Many of these tips really matter: should dependencies be created and be in the project I’m working on?
I always ask this question to myself, and if the specific problem I’m trying to solve is clear enough, I can even pull out the code, copy the license and quote the source so that I have a completely frozen addiction.
![[Для читателей][Тизер] Nishtyakovy roadmap for the month of December](https://prog.world/wp-content/uploads/2022/11/6bf53776da2d2098fb3f12f7f94c8df4-768x1365.jpeg)
