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.
...
For further actions, you may consider blocking this person and/or reporting abuse
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 withcomposer.jsonand 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.
We loved your post so we shared it on social.
Keep up the great work!
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
Thank you.
I agree is-odd should be in every library 😊
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. 😏
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.
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 😊
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.
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?
Good