Vet Laravel Package

Getting Started

Install it as a dev dependency and pin the exact version. This is pre-1.0 with a config schema; a caret constraint means a composer update on a Tuesday can change vet.json semantics under you.

composer require --dev laravel/vet
composer show laravel/vet   # confirm what you actually installed

The provided sources describe "an Artisan command" but never print its signature. Find it before you script anything:

php artisan list | grep -i vet

Run it once by hand, then capture the exit code immediately — that is your future CI contract:

php artisan vet; echo "exit=$?"

Repeat for a passing config, a failing config, and a malformed vet.json. Assert all three in a two-line CI test so a minor bump that changes exit codes fails in one obvious place instead of silently disarming your gate.

Read in this order:

1. vet.json at the repo root. Since v0.2.1 this file may be near-empty — just minimum release age settings. Start from the smallest viable file, not from a schema someone pasted into a blog post.
2. src/. There is no user manual here; the shipped docs are a changelog and a contributor guide written for coding agents. The actual rule set lives in code. Budget an hour to answer one question: does this version perform the Laravel code checks the manifest description advertises, or only the dependency trust-file checks the changelog documents?
3. Releases. Treat every entry as a possible schema migration and review it like a PR.

First day's use case: one rule, one repo, no gate. Commit a vet.json that quarantines versions published in the last 7 days. Run it locally on a non-critical repository and add a single CI step that runs it and does not fail the build. After a week you have the diff of what the policy would have flagged — that is your data for deciding whether enforcement is worth the friction.

Implementation Patterns

Treat vet.json as the deliverable, not the command. The durable output of adoption is a committed file that states which dependency versions are admissible here. Name an owner. Exceptions are a PR to that file, dated, attributed, and reversible. No overrides agreed in Slack. This is the whole argument for the tool: policy review moves into the PR that motivated it, and gets smaller.

Ratchet in three stages, not one.

• Weeks 1–2: run on every branch, fail nowhere. Measure wall-clock runtime against your largest lockfile; that number decides whether this can sit on the critical path.
• Weeks 3–6: fail only on PRs that touch composer.json or composer.lock. Blast radius is bounded to changes that actually warrant scrutiny, and unrelated PRs stay fast.
• Week 7+: gate all dependency-changing merges, plus a scheduled weekly re-audit of untouched lockfiles to catch drift.

Watch the blocked-bump rate through the ratchet. If bot-opened patch bumps keep getting blocked with no remedy, your threshold is wrong or your ordering is wrong — fix the config, don't add exceptions.

Sequence it after composer audit and Dependabot/Renovate. Those answer "what has CVEs" and "when do we move." Vet answers "which versions are admissible." Reversed, week one reads as "this tool blocks security fixes," and you lose the argument for keeping it. In the PR template, describe what vet enforces precisely — "version-age and package-trust policy" — because the word "audit" invites reviewers to assume CVE coverage that is not there.

Incident freeze as a commit. During a supply-chain scare, "freeze new packages" becomes a one-line vet.json change with an author and a timestamp, visible in the PR that caused it. Write the rollback — revert that commit — into the runbook at the same time you write the freeze, not mid-incident.

Companion, not replacement. Vet does not scan advisories and does not emit an SBOM. Keep composer audit in the pipeline beside it. Two steps, two jobs.

Bootstrap small. v0.2.1's fix exists because a near-empty config used to be fragile. Take advantage of it: start with only the release-age setting, add a rule only when you have a specific fault motivating it. Every extra rule is another thing to explain at 2am.

Monorepo: one vet.json per lockfile if services resolve independently, not one at the root. Verify how the command locates the file before you standardise on a layout — that behaviour is not in the provided sources.

Gotchas and Tips

The scope ambiguity is the headline risk, and it is a process risk, not a code risk. The manifest description sells Laravel-aware static analysis — request input, mass assignment, queries, views, "PHPStan-powered." The changelog and config surface describe a Composer trust file whose only documented rule is minimum release age. Those are different products with different buyers. Resolve it by reading src/ on the version you pinned before anyone writes "AppSec scanner" on a roadmap slide.

Pin exactly; review each minor as a PR. Pre-1.0 plus a config schema means silent CI breakage is the default failure mode. Budget review time per release.

Zero dependents means every edge case is yours. At 185 stars you are among the first production users. There is no community answer bank. When something looks wrong, reading src/ beats searching issues — and if you find a bug, budget for maintaining a fork rather than waiting on a merge.

Governance quirk if you plan to contribute. The repo is developed under a .hod/ + AGENTS.md model written for coding agents: strict separation of intent from code, no comments in code, public text governed by separate rules. Fine as a consumer; it means upstream patches have an unusual shape and a slow path.

Private registries, path repositories, and VCS dependencies are the unverified surface — and it is the surface that matters. Your riskiest dependencies are exactly the ones most likely to be skipped. Determine whether they are skipped or failed, and whether that is configurable. If it fails open, your enforcement design is a suggestion, not a control, and any security review assuming coverage is wrong.

Age checks imply network calls to Packagist. Outages become build outages; air-gapped and egress-restricted runners become a problem. Test on a runner limited to your internal mirror before phase 2, and decide explicitly whether offline fails open or closed.

Verify transitive coverage and lockfile semantics. Direct require/require-dev only, or transitive too? Does it read composer.lock or re-resolve? Drift between those two decides whether results are reproducible across machines — which decides whether the gate is trustworthy.

Exit codes are your integration contract; the sources do not enumerate them. Derive them empirically and assert them in CI, as above. This is the single cheapest piece of insurance against a quiet minor-version regression.

Debugging loop when a run surprises you: confirm vet.json parses and sits where the command expects; confirm composer.lock is committed and current; then re-read src/ for the rule you believe fired. There is no documented -v, so bisect the config by removing rules rather than hunting for verbosity.

The advertised last release date is 2026-09-27 — a future date. Verify what you actually installed before that date appears in an SLA, an audit narrative, or a deck.

Extension point to watch. The claimed "configurable checks" surface is the thing to understand before committing. Write the policy you actually want in vet.json and let it fail. If the rule is not there, that is your answer about scope — and a config file is a far cheaper way to learn it than a six-week rollout.