When should you NOT use Dependency Management Philosophy?

Adding a package for a feature you could implement in 10 lines — every dependency is a supply chain risk. Ignoring outdated dependencies — stale packages accumulate security vulnerabilities. Committing vendor directories to version control when a lock file is sufficient. Using broad version constraints (^1.0) without testing — minor updates can introduce breaking changes.

When is Dependency Management Philosophy the right choice?

Pin exact versions in production lock files — deterministic builds prevent surprise breakage. Audit new dependencies for maintenance activity, license compatibility, and known vulnerabilities before adding. Automate dependency updates with Dependabot or Renovate — humans do not reliably update dependencies. Separate dev dependencies from production dependencies — only production code ships to users.

← Back to glossary

Dependency Management Philosophy

General PHP 5.3+ Intermediate

debt(d5/e5/b7/t5)

d5 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'specialist tool catches' (d5). The term's detection_hints.tools lists composer-audit, dependabot, snyk, and roave-security-advisories — all specialist security/dependency scanning tools that must be explicitly configured in CI. Default linters won't catch missing composer.lock commits or abandoned packages; these require dedicated tooling.

e5 Effort Remediation debt — work required to fix once spotted

Closest to 'touches multiple files / significant refactor' (e5). While quick_fix suggests running composer audit is trivial, the common_mistakes (composer.lock not committed, no licence review, depending on abandoned packages) require touching multiple files and potentially replacing packages across the codebase. Switching from an abandoned package to a maintained alternative often requires code changes throughout the application.

b7 Burden Structural debt — long-term weight of choosing wrong

Closest to 'strong gravitational pull' (b7). The applies_to shows this affects all PHP contexts (web, cli). Dependency choices are load-bearing across the entire system — every component relies on the dependency tree. A bad dependency choice (abandoned package, licence conflict, security-vulnerable library) shapes every future decision and forces workarounds. The misconception explicitly notes dependencies add 'security surface, conflicts, licence risk, and maintenance burden' that compounds over time.

t5 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'notable trap' (t5). The misconception field states 'More dependencies save time' is the canonical wrong belief — this is a documented gotcha that most developers eventually learn through painful experience with supply chain issues, version conflicts, or abandoned packages. It's not catastrophic (experienced developers know to audit dependencies), but it contradicts the naive assumption that adding packages is purely beneficial.

About DEBT scoring → scored by claude-opus-4-5-20251101 · 2026-05-07 · reviewed by human

Also Known As

dependency management composer lock left-pad

TL;DR

Every dependency is a liability — prefer few well-maintained packages; pin versions via composer.lock; audit regularly.

Explanation

Principles: prefer stdlib, prefer widely-used over niche, check licence (GPL contamination risk), pin versions (composer.lock), audit regularly (composer audit). Left-pad problem (npm 2016): a widely-used 11-line package was unpublished, breaking thousands of projects. Each dependency adds: security attack surface, version conflicts, licence risk, maintenance burden.

Common Misconception

✗ More dependencies save time — each adds security surface, conflicts, licence risk, and maintenance burden.

Why It Matters

Dependency management is not just about installing packages — it is about controlling what code runs in your application. A compromised or malicious package in your dependency tree can exfiltrate data, install backdoors, or corrupt your build. Pinning exact versions in composer.lock and running composer audit regularly catches known vulnerabilities before they reach production. The supply chain attack surface through third-party packages is now the most common vector for large-scale compromises.

Common Mistakes

composer.lock not committed
composer update in production
No licence review
Depending on abandoned packages

Avoid When

Adding a package for a feature you could implement in 10 lines — every dependency is a supply chain risk.
Ignoring outdated dependencies — stale packages accumulate security vulnerabilities.
Committing vendor directories to version control when a lock file is sufficient.
Using broad version constraints (^1.0) without testing — minor updates can introduce breaking changes.

When To Use

Pin exact versions in production lock files — deterministic builds prevent surprise breakage.
Audit new dependencies for maintenance activity, license compatibility, and known vulnerabilities before adding.
Automate dependency updates with Dependabot or Renovate — humans do not reliably update dependencies.
Separate dev dependencies from production dependencies — only production code ships to users.

Code Examples

✗ Vulnerable

// Non-pinned: different versions on dev/CI/prod

✓ Fixed

// Checklist: <50 lines to DIY? Maintained? MIT licence? Audit in CI
git add composer.lock

References

https://getcomposer.org/doc/01-basic-usage.md#commit-your-composer-lock-file-to-version-control