How I evaluate dependencies

I like to comment on new features, new libraries and new frameworks.
That is why I want to give more context how I come to my conclusions.

The less dependencies the better

At the start of a project or a new feature the functionalities are identified and then those are matched with the possibilities of the language.
When the functionalities are out of scope for the language. The functionalities are matched with libraries, standalone or framework dependent.
If enough functionalities have a framework match, the framework dependencies get priority.

Don't use dependencies with the same functionality

I see a lot of libraries that bring with them functionality that is already present in the code base by another library or custom code. For me that is a reason not to use it.

When I talk about the same functionality I'm not talking about helper libraries like a test library, but about the core functionality of a library.

Dependencies should be composable.

Can it be custom code

There are people that believe adding dependencies is better because it saves the project from maintaining the edge cases and security risks. While it is certainly a factor in the decision process, it should not become a dogma.

With AI code generation the statement of the dependency gets us 90% there is becoming blurry. The main reason is because that 10% could bring with it as much development time as a 100% AI generated solution.

The maintenance is still a factor, even with AI generated code. My experience is that the 10% code is not documented most of the time, and that is why people are hesitant to change working code.
With custom code this could be documented from day one.

Conclusion

Deciding to use a dependency should be a well throughout process to make the best decision in the long run.

You should see it as adding salt to food. If there is too little, it is possible to add more. Once you added too much, it is harder to dilute the taste.

Comments

[spO0q]

There are some warning signs that indicate you should probably ditch the external packages.

For example, when you make too many changes, you'd probably better build your own stuff considering the time you spent on those dependencies.

Although, there are interesting approaches such as Patch Package that allow more flexibility while keeping the core features.

I also prefer the "less is more" approach, but, as you mentioned it, it should not become a dogma, so 0 dependency seems unrealistic, but dependency hell is a real problem in software development.

It raises security issues but it's also problematic for the global maintenance.

A good example would be free templates. Sometimes, you find pure duplicates in package.json (it's quite the same with composer.json and other package managers). It "forces" you to ship and maintain with useless dependencies, as many have the exact same purpose.

You can even solve bugs just by removing a dependency without changing anything else.

[Ivan Mykhavko]

Thoughtful take 👍
At first, those packages may seem like they speed up development, but once you realize they’re not a perfect fit, you end up struggling with configuration instead of implementing something simple.
But sure sometime you can find something valuable, for example: npmjs.com/package/is-odd

[david duymelinck]

Thank you.

I agree is-odd should be in every library 😊

[Lars Moelleken]

Every cash cow project (legacy makes the money) that I was paid to modernise was created with only a few dependencies; most of the core logic was independent of dependencies, perhaps because there was nothing of good quality available to use at the time, or perhaps that is precisely why it worked for so long (10-20 years). Who knows. 😏

[david duymelinck]

I don't think code quality is a problem. A dependency can be more qualified, because the people that work on it know the problemspace better.
I think the biggest problem is maintaining the few features of the dependency that are not compatible with the project.

Most of the times when the core logic is solid, only a big language change could trigger a code rewrite.

[Sylwia Laskowska]

I’ll admit that at first I thought: “oh come on, we need dependencies!” Then I remembered that one project where they really made sure to keep them to an absolute minimum — they didn’t even let me add Lodash… Yeah, it was a super stable project 😊

[david duymelinck]

I think we all have our goto libraries, but it is good to challenge them once in a while to see how much value they have kept along the years.

[Pascal Reitermann]

Dependencies can introduce breaking changes, forcing you to either adapt your codebase or migrate to an alternative. Both options are time-consuming, and let's be honest: who has that kind of time nowadays?

[Nadeem Zia]

Good