Why Use Deadpendency?

TL;DR

  • Dependency updates are a chore, but are essential over the long term. The best way to manage these updates, is to proactively keep dependencies up to date.
  • Thankfully, there are amazing automated dependency update tools.
  • There is a gap though, a dependency that has become a dead project will never have another update released. A 'dead' dependency has the same downsides as an un-updated dependency.
  • Deadpendency is a tool to report on and alert when your dependencies become unhealthy software projects. For example, the project becomes inactive, or is deprecated.
  • This automates what is currently an ongoing manual process (or oft neglected) to enable maximum dependency health. Deadpendency should be used in conjunction with automated dependency update tools (where possible).

Software dependency updates are essential

A given release of an application works for a given set of dependencies and for a given platform. While the application code will not change, the dependencies and platforms continue to change introducing incompatibilities. This process is often referred to as bitrot.

Bitrot is especially prevalent in modern software development, with most programming languages and other platforms having major updates yearly if not more frequently. The whole ecosystem including applications need to keep pace.

Dependencies should be regularly and automatically updated

To avoid application code falling behind platform and dependency churn, updates should be regularly applied. Avoidance of dependency updates leads to large 'big bang' updates which are more risky and time consuming.

Ideally, the dependency update process should be automated as much as possible.

Dependencies sometimes will become 'dead' projects

In open source, projects will sometimes become inactive, or be superseded. A 'dead' dependency locks you into an aging version that again subjects the application to the problems of bitrot.

However, automated dependency update tools will not alert you to this issue, as the application is already on the latest version. Thus, to be in the best possible state around dependencies, you need to be updating dependencies AND checking dependencies are still being actively maintained and released.

Dependency project health tracking is currently manual

Dependency project health tracking is currently a manual process. It involves keeping abreast of these projects and checking that there are still regular commits and releases. The process is ongoing as healthy dependencies now may become inactive in the future.

Due to the time consuming effort of this health tracking, it is oft neglected and applications will unknowingly depend on 'dead' dependencies.

Sometimes applications need to depend on inactive dependencies as there are no viable alternatives. However, in some cases there are excellent alternatives and this is when dependency project health tracking provides the most value.

Deadpendency automatically tracks and alerts on project health

Deadpendency automatically checks dependency project health upon every git push. It enables developers to be informed about dependencies that have become inactive so they can make informed choices.

The check is ongoing. As an application is worked on and git pushes made, the Deadpendency check is continually run. Any unhealthy dependencies will fail the check, alerting developers to the issue with minimal effort required.

Other benefits of Deadpendency

A complete dependency project health report

Each push produces a dependency project health report (in the form of a GitHub check run, see this example). The report gives a quick snapshot of dependency project health, including links to the package and the source repository to enable additional review. Dependencies that are becoming unhealthy will have warnings, but will not fail the check.

Fast feedback on pull requests

Deadpendency will run when a pull request is submitted. This means that if the pull request adds a new dependency, it will automatically have its project health checked.

In the scenario where the dependency is not being healthily maintained, this is flagged in the report. Thus the submitter is prompted to either select some alternative, or justify the unhealthy dependency's inclusion. This alleviates the pull request reviewers from manually doing this assessment and giving the feedback.

Avoid depending on old forked dependencies

In some cases, a dependency will have a bug. The quickest way to deal with this is usually to fork the dependency and fix the bug. Then the application can depend upon the forked version, without requiring any assistance from the dependency's developers.

However, it can take a while for this fix to be upstreamed into the dependency and for a new version to be released. Often developers will forget to switch back when the fixed version is available. Dependency update tools will typically ignore new versions as the dependency is being pulled in from a git repository.

Deadpendency immediately flags the dependency with a warning as it is using a fork. Over time, the fork will not be getting commits and will be flagged as unhealthy, reminding developers to switch back to the un-forked version.