Patrol Laravel Package

Product Decisions This Supports

• Dependency-hygiene triage as a measurable backlog. Patrol gives you a concrete, countable artifact — candidate unused/outdated packages, advisory exposure, vendor-directory weight — that turns "our dependency tree is bloated" from a vibe into a ticket with an owner and a size. That's what feeds quarterly tech-debt prioritization.
• Pre-upgrade scope reduction. Ahead of a Laravel or PHP runtime upgrade, Patrol is a cheap first pass to shrink the dependency graph before the upgrade gets estimated. Fewer packages = fewer transitive pin conflicts, less upgrade work, faster composer update cycles.
• Build vs. buy, decided on evidence. Building this in-house means AST parsing, namespace-to-package mapping, and edge cases around Laravel's string-based resolution. Patrol is MIT and installs in one command, so "buy" wins on cost — but only as an advisory utility, never a load-bearing platform component. Run it as a bake-off against composer-unused + native composer audit / outdated, and let the results drive the call.
• Supply-chain and attack-surface narrative. Fewer reachable dependencies means fewer CVEs to triage, fewer abandoned packages, smaller surface for security. Treat this as a supporting input to a security roadmap — not a substitute for composer audit, SBOM generation, or license-policy enforcement.
• Deployment footprint. For serverless or container deploys, vendor-directory size hits image size and cold start. Patrol produces a defensible drop-list for the production build.
• Roadmap placement. The right home is a nightly, non-blocking CI report on a platform-health track — not a merge gate. Findings require human verification, so gating on it manufactures false-positive churn and erodes trust in CI.

When to Consider This Package

Adopt it when:

• You have a PHP/Laravel codebase with a large, accretion-built dependency list (roughly 50+ direct deps, multi-year history).
• You already run CI and can add a scheduled, non-blocking job with a published artifact.
• Someone is named as owner of the output. Without an owner, the report is noise.
• There is a live trigger: framework upgrade, security audit, container-size reduction, or a "cut dependency count by 20%" OKR.
• You pin the version and accept that it's a single-maintainer, low-adoption tool (280 stars, 0 dependents, overall score 2.33).

Look elsewhere when:

• Compliance or regulated environments need vendor support, an SLA, or a maintained release cadence. Standardize on composer-unused + composer audit + a real SBOM tool instead.
• The codebase resolves classes dynamically — container bindings by string, config-driven class names, package auto-discovery, morph maps. Static "unused" verdicts will be wrong often enough to be dangerous; every finding is a hypothesis, and every removal needs a reviewed, test-covered PR.
• You need license enforcement or CVE reporting. Different tools, different job.
• Monorepos with path repositories. Package-to-usage mapping gets murky fast.
• You want to automate removal. No version of this should delete a dependency without a human and a green test suite.
• The team can't absorb another tool. If dependency hygiene isn't on the roadmap, adopting this is shelfware.

Practical adoption path: one-sprint spike, dev-dependency only, pinned version, nightly advisory report, hand-verified removal PRs capped at a few packages per week, explicit retire decision at the end.

How to Pitch It (Stakeholders)

To executives (30 seconds): We ship Composer packages we don't use and can't justify. That's maintenance cost, security surface, and upgrade friction we pay for every month. Patrol is a free, MIT-licensed developer tool — it adds nothing to production, carries no runtime risk, and takes roughly a day to wire up — that produces a concrete list of what we can safely drop. Expected outcomes: a smaller dependency tree, fewer CVEs to triage, and measurably less work in our next Laravel upgrade. Cost: about one engineer-week including triage. Fully reversible; the tool can be dropped without touching application code.

To engineering (the honest version): Dev-only CLI, no service provider, no config required beyond install. Run it nightly in CI as a non-blocking job and archive the report; do not gate merges. Findings are candidates, not verdicts — static analysis misses string-based container bindings, config-driven class names, and auto-discovery, so every removal needs a reviewer and a passing suite. Pin the version explicitly — this is a single maintainer with 280 stars and zero dependents, and its core function overlaps heavily with native composer audit and composer outdated. Treat it as a reporting convenience with a documented fallback, not a capability acquisition.

Risks to state up front: low community signal (the 7.87 opportunity score is attractive, but the 2.33 overall reflects thin adoption and likely stagnation); false positives in dynamically-resolved code; bus-factor of one; and overlap with native Composer commands creating two sources of truth. Mitigation: advisory-only posture, pinned version, a named internal owner, and a runbook entry naming composer audit as the authoritative fallback. If Patrol surfaces nothing native tooling misses within one or two sprints, retire it — that is a successful outcome, not a failed experiment.

Success metrics: packages removed per quarter, vendor-directory size delta, dependency-tree CVE count, and time-to-complete on the next framework upgrade.