Paper 02: Failure Modes in Client-Side Dependency GraphsAuthor: Engineering Team, Binary & Bus, Sys.
Published: 3rd September, 2026
Status: Research Paper
Abstract: A production web application's dependency graph is rarely audited as a single object of study; it is instead treated as an emergent side effect of individual package decisions made over the life of a project. This paper analyses the dependency graphs of nineteen client codebases audited by Binary & Bus, Sys. during onboarding between 2024 and 2026, quantifying graph depth, transitive package count, and maintainer concentration, and correlates these structural properties against the incidence of build failure, security advisory, and unplanned emergency support work in the subsequent twelve months. We find that transitive depth, not direct dependency count, is the strongest predictor of instability, and set out a bounded-depth standard we now apply to new engagements.
1. Introduction
When a client engages us to take over maintenance of an existing system, the first action our team takes is not a review of the application code but a review of its dependency graph: the full set of packages the build actually resolves, direct and transitive, and the maintainers responsible for each. This is a deliberate ordering. Application code fails in ways the team that wrote it can usually anticipate; dependency graphs fail in ways no one on the client's team is positioned to anticipate, because the failure originates outside the codebase, in a package several levels removed from any line of code the client's engineers have read.
This paper treats the dependency graph as a structural property of a system with measurable risk characteristics, in the same way an engineer would treat a physical load-bearing structure, rather than as a simple inventory of tools. Our working assumption, stated plainly, is that a system's fragility is a function of how many parties outside the client's control can independently break it, and that this number is not obvious from a package.json file's direct dependency list alone.
2. Methodology
For nineteen client codebases onboarded between January 2024 and April 2026, we recorded, at the point of onboarding: direct dependency count, total resolved transitive dependency count, maximum dependency graph depth (the longest chain from the application to a leaf package), and maintainer concentration (the proportion of the full dependency tree maintained by a single named individual or a team of two or fewer, based on published package registry metadata). We then tracked, for the following twelve months of our own maintenance of each system, the number of forced dependency updates driven by a published security advisory, the number of CI or build failures attributable to an upstream package change, and the number of emergency (same-day) support requests attributable to a dependency-originated fault.
Codebases were drawn exclusively from onboarding engagements, meaning none were systems we had built ourselves, which avoids the obvious bias of auditing our own prior work. All nineteen were JavaScript or TypeScript web applications, since that was the common language of the client base available to us; we do not claim these findings generalise to other ecosystems without further study.
3. Results
Structural property Low-incident (n=11) High-incident (n=8) ------------------------------------------------------------------------------ Median direct dependencies 34 41 Median transitive dependencies 412 1,847 Median maximum graph depth 6 14 Median single/pair-maintainer share of tree 22% 58% Security advisories triggering a forced update 0.4/yr 3.9/yr Dependency-attributable emergency requests 0.2/yr 2.6/yr
Direct dependency count was similar between the group of systems that went on to generate frequent incidents and the group that did not, and was a poor discriminator on its own. Transitive dependency count and, more strongly, maximum graph depth separated the two groups clearly. Maintainer concentration was the single strongest correlate we measured: systems where more than half of the resolved dependency tree traced back to a single maintainer or a pair of maintainers experienced security-driven forced updates roughly ten times more often than systems with broader maintainer distribution.
4. Discussion
The intuitive proxy for dependency risk — how many packages a team explicitly chose to install — is the wrong measure, because it is not the packages a team chose that generate most incidents, it is the packages those packages chose, several layers removed and typically unreviewed by anyone on the client's team or ours at the point of installation. A single convenience utility with a shallow, well-maintained dependency tree of its own contributes negligible structural risk; the same utility, if it transitively pulls in a deep chain terminating in packages maintained by a single unpaid individual, contributes disproportionate risk that is invisible unless the full tree is inspected.
Maintainer concentration deserves particular attention because it is a governance property, not a technical one, and it degrades independently of code quality. A well-written package maintained by one person is one missed update, one abandoned repository, or one compromised account away from becoming a liability, regardless of how sound its code was at the point of adoption. We regard maintainer concentration as an underweighted criterion in most dependency selection practice, including, at times, our own earlier engagements, several of which are represented in the high-incident group in this sample.
5. A Bounded-Depth Standard
Based on these findings we now apply a working standard to new bespoke engagements: a target maximum dependency graph depth in the single digits, an explicit review of maintainer concentration before adopting any package that would materially deepen the graph, and a strong preference for zero-dependency or near-zero-dependency implementations of functionality that is not the client's core differentiator. This standard is a direct extension of the minimal, document-first architecture we set out in our companion position statement on front-end overhead, applied to the build-time dependency graph rather than the runtime payload.
6. Conclusion
A dependency graph is a structural commitment with a risk profile that can be measured and bounded, not a neutral list of convenience. Engineering teams evaluating a codebase, whether their own or one they are inheriting, should audit transitive depth and maintainer concentration directly rather than relying on direct dependency count as a proxy, since our data indicates the proxy is a materially weaker predictor of the incidents that actually consume unplanned engineering time.