Pathogen Laravel Package

Product Decisions This Supports

• Build vs. buy vs. reuse on path primitives. The decision this package actually informs is not "adopt or not" but "what tier does path handling live in." Verdict: path manipulation is undifferentiated plumbing, so it belongs in reuse — but only from a maintained source already in our dependency graph (Symfony Filesystem, Flysystem, or native functions). A 2014-era archived library converts "reuse" into "own."
• Dependency policy: defining the "abandoned utility" gate. pathogen is a useful forcing function for codifying adoption criteria — last release within 24 months, declared support for our current PHP minor, an active maintainer, and a passing composer audit. It fails three of four, which makes it a clean worked example for the policy rather than a policy exception.
• Roadmap: explicitly de-scoped. Path handling is table stakes with no user-visible differentiation. The 0.53 opportunity score reads as modest latent demand for path ergonomics — real, but already satisfied by components we ship today. No roadmap slot.
• Security posture review. Path code is adjacent to path traversal, normalization, symlink resolution, and upload sandboxing. An unmaintained library in that seam carries unbounded CVE-response liability with zero upstream to absorb it. This is a risk-register entry, not a feature decision.
• Legacy triage classification. If pathogen appears in an existing composer.lock, it opens a remediation ticket (wrap, instrument, schedule removal), never a capability ticket. That classification decides which backlog it lands in and who owns it.

When to Consider This Package

• Only if you are sustaining a legacy codebase that already depends on it and cannot be refactored inside the current cycle. Even then, adopt the exit plan in the same breath as the decision to keep it.
• Consider the pattern, not the package: the immutable path value object (join, normalize, relative, extension handling) is a good ergonomic idea and worth mirroring in your own thin internal helper if you need one.
• Look elsewhere — decisively — when any of the following hold:
  • Greenfield work, or anything targeting PHP 8.x.
  • Security-sensitive surfaces: file uploads, tenant isolation, user-supplied paths, symlink handling.
  • You need composer audit to come back clean or you operate under SOC 2 / ISO supply-chain review.
  • You need remote or stream-backed filesystems, not just local paths.
  • Your team has no appetite to own a fork.
• Alternatives that clear the bar: symfony/filesystem (Path, Filesystem), league/flysystem (path prefixing and normalization), or plain pathinfo/DIRECTORY_SEPARATOR helpers for trivial cases. Prefer whichever is already transitively installed — adding zero net dependencies is the ideal outcome.

How to Pitch It (Stakeholders)

• To executives, one line: "We looked at a path utility library. It's been archived since October 2014 with no maintainer, so we're not taking on that ownership. We'll use a maintained component we already ship — no new cost, no new risk, no schedule impact."
• To engineering, one line: "Don't add it. If it's already in your composer.lock, wrap the call sites behind our own small path helper this sprint and schedule removal next; here's the symbol-to-symbol mapping to Symfony's Path."
• Frame it as a cost question, not a quality question. The library is MIT-licensed and probably fine code. The problem is total cost of ownership: a dead dependency means we become the maintainers, and the moment a PHP minor breaks it or a traversal edge case surfaces, the fix is ours. That is a recurring engineering tax on a component users will never notice.
• Lead with the security adjacency. Path handling sits next to the code that decides which files a user can reach. "No upstream to issue a patch" is the sentence that closes the conversation with security reviewers.
• Give the positive recommendation, not just the veto. Stakeholders accept a "no" far better paired with a "yes": we standardize on the maintained path API already in our stack, we extract a thin internal helper if ergonomics genuinely hurt, and we revisit only if path handling becomes a differentiated capability — which it won't.