Pet Laravel Package

Technical Evaluation

Architecture fit. Vet remains a dev-time static analysis CLI for Composer dependency graphs — it audits what is already in composer.lock rather than instrumenting the application. No service provider, container bindings, middleware, or production config surface. It sits in the same tier as PHPStan, Pint, and Rector and should be governed by the same quality-gate policy. One refinement prompted by v0.2.1: the tool now demonstrably reads a committed, repo-local declarative config (vet.json), which means it introduces a versioned artefact into each repository — small, but it is a file engineers will edit, review, and eventually copy between repos. That shifts Vet marginally from "pure CLI flag-passing" toward "policy-as-config," which is a better fit for fleet-wide governance but adds a schema to own.

Integration feasibility. High. Install is a single composer require --dev line or global install; invocation is a CLI command suitable for a CI step, pre-push hook, or scheduled job. v0.2.1 confirms the two integration properties that matter: (a) configuration is file-based and therefore reviewable and diffable in PRs, and (b) the config supports at least one policy primitive beyond advisories. The remaining unknowns are unchanged — non-zero exit on findings, severity threshold flags, and machine-readable output — but the existence of vet.json makes a machine-readable config surface likely and gives a natural place for a central baseline.

Technical risk. Low absolute risk, moderate decision risk. v0.2.1 is a patch with no breaking changes; it does not alter the risk profile materially, but it reveals capability and maturity signals that do:

Key questions to resolve before a pilot.

1. What exactly does the minimum release age setting evaluate — direct dependencies only, or the full transitive graph? Does it read publish timestamps from Packagist, and what does it do for path repositories, VCS repositories, and private packages with no publish time?
2. Is the minimum age a single global value, or can it be scoped per package/constraint? What is the documented override path for an urgent security upgrade — inline exemption, allowlist, or CLI flag?
3. Is the vet.json schema documented and versioned, and is there a compatibility guarantee for it across 0.x minors?
4. What does Vet report that composer audit does not, now that minimum-age is on the table — and is that delta worth a second tool in the pipeline?
5. Does it exit non-zero on findings, and is there a severity or category threshold flag (advisory findings vs. age findings gated independently)?
6. Is there JSON/SARIF output, and is the schema stable across minor versions?
7. What is the advisory source and refresh cadence, and is there an offline/cached mode for air-gapped CI?
8. Which PHP and Composer versions are supported, and does that cover the full matrix of our projects?
9. Who maintains it, and is there a stated support commitment or single-maintainer bus factor?

Integration Approach

Stack fit. Strong for a Laravel/PHP estate on Composer 2 — no polyglot friction, no separate runtime, no sidecar. The committed vet.json fits existing repo conventions alongside phpstan.neon, pint.json, and .php-cs-fixer.php, and gives a natural anchor for a shared baseline.

Migration path. Nothing to migrate. Purely additive. Frame as trial with an explicit exit criterion so removal is a non-event.

Compatibility. Three axes now, not two: the tool's PHP constraint against the oldest PHP in the CI matrix; behaviour on monorepos and path repositories where composer.lock and publish-timestamp semantics differ; and the vet.json schema against whatever shared baseline you publish. Test the minimum-age feature specifically on the repo with the most path/VCS dependencies — that is where timestamp resolution is most likely to be undefined or wrong.

Sequencing.

1. Verify identity — confirm Composer package name, repo, and tag provenance. Resolve the naming discrepancy in writing. Blocking.
2. Shadow mode — run on one representative repo, non-blocking, output to an artifact. No gate. Include vet.json with minimum-age enabled but non-enforcing so you can see what it would have caught.
3. Measure the delta — compare against composer audit over 2–3 weeks. Count unique findings, split advisory findings from age findings, count false positives and time-to-triage.
4. Tune — set the minimum age value deliberately (start permissive), establish a waiver list with owner and expiry, define a severity threshold and separate gate decisions for advisory vs. age findings.
5. Gate — promote to blocking on new findings only (grandfather existing debt), then widen to the fleet.
6. Schedule — weekly non-gated run to catch advisories published against unchanged dependencies. Note: the minimum-age check is inherently time-dependent, so it only produces value on a recurring run, not just at PR time.

Operational Impact

Maintenance. Near-zero engineering cost: a pinned dev dependency, one CI line, one small committed config file. The real maintenance is policy maintenance — waiver hygiene, severity thresholds, and now the minimum-age window, all of which drift if unowned. Assign a named owner for the waiver list and the age threshold, or they become a graveyard of suppressed findings. Pin the exact version: a pre-1.0 config schema plus a CI parser downstream is a fragile combination.

Support. Community-only, MIT, effectively single-maintainer. No vendor SLA. Escalation path for a blocking false positive is "patch locally or disable the gate" — acceptable for dev tooling, but document it as the accepted fallback so teams don't improvise under release pressure.

Scaling. Cost scales linearly and cheaply with repo count and CI minutes. The limit is organisational: at ~20+ repos, per-repo vet.json files diverge and the same advisory or age violation is triaged independently by every team. The existence of a config file makes a shared baseline feasible — plan a central config repo (or a published preset) from the start rather than retrofitting one.

Failure modes.

• Minimum-age blocks an urgent security upgrade → highest-probability new failure; mitigate with documented per-package overrides and a break-glass bypass agreed with security before the first incident.
• Undefined publish timestamps → path repos, VCS repos, and private packages may be skipped or misreported; verify behaviour explicitly rather than assuming.
• Advisory/registry source unreachable → job fails or silently passes depending on default; configure fail-open for availability, with the scheduled job as the safety net.
• False positive blocking a release → mitigate with thresholds and a documented bypass.
• Stale feed → reports clean while a known advisory exists; monitor feed freshness, not just exit code.
• Config schema change on a minor bump → pinned version mitigates; add a CI check that the committed vet.json parses under the pinned version.
• Silent disablement → track "gate active on N of M repos" as the adoption metric, not install count.

Ramp-up. Under a day for an engineer to install and interpret. The expensive part is the 2–3 week shadow period needed to build trust in the signal, plus a short calibration of the minimum-age value against real release velocity. Budget for it — teams that gate on day one and get burned will not re-adopt.

Verdict on v0.2.1. A low-risk patch, but a useful signal: it confirms a reviewable config surface and surfaces a capability — release cooldown — that is a credible reason to run Vet alongside native composer audit. No change to the overall recommendation: a cheap, reversible, low-ceiling bet worth a scoped pilot, still contingent on resolving the package-identity question and validating the minimum-age behaviour on the messiest repo first.