Sign in

Development dependencies considered harmful

3 ▲
Henri Bergius
48 days ago · Tech · hide · 5 comments

Time is a precious resource for open source maintainers, especially if you aren’t doing it as part of paid work. The constant churn of changing development tools steals a huge chunk of that time. For example, I’m running NoFlo on a daily basis, but do changes to the library itself quite rarely. There were nearly six years between releases recently. The other day I wanted to add some functionality, and ran immediately to a huge set of issues with the development tooling we use. Basically everything we rely on is deprecated and has a huge set of security issues. Just to show some: Karma, which we use to run browser tests is deprecated since 2023 eslint has made a huge backwards incompatible release, and the AirBnB rules we use haven’t been carried over On top of these our test runner, the assertion library, coverage checker, etc all have major releases out. Not upgrading means having a growing list of security warnings on every install. At worse they may affect the security of your…

Log in to reply on the Fediverse. Comments will appear here.

  • Fin @finjb@defcon.social 48 days ago

    Ok, it’s always a good thing to not bring on too many dependencies obviously.

    I think rejecting the concept altogether is throwing the baby out with the bathwater. You just need to keep up with the updates instead of waiting until everything is out of date and it would take a ton of trouble to upgrade.

    There are tools like dependabot and renovate that help you keep up-to-date on your dependencies. Or you can even just run pnpm update —latest every once in a while. (Or its equivalent in whatever package manager you use).

    reply
    • Henri Bergius @bergie@pixelfed.de 47 days ago
      Having used first greenkeeper and then dependabot in dozens of projects, they can indeed help a bit. But mostly by just spreading the workload across time. So if you do you weekly "check all dependency update PRs", then maybe your repo is ready to go the next time you want to do actual work on it. But honestly, even that weekly workload is a lot.
      reply
      • Fin @finjb@defcon.social 47 days ago

        @bergie I guess I haven’t worked on any HUGE projects using these, so you may know more than I do. So far though my experience with renovate is that the hardest part is for someone to remember to click the approval button every so often otherwise the PRs back up.

        Occasionally there is a major package upgrade that requires some code adjustments. And also there are sometimes some packages that fail pnpm’s trust requirements that require some examination.

        Other than that I greatly prefer amortizing the effort over time than waiting for things to pile up.

        reply