Laravel Baseline Laravel Package

Product Decisions This Supports

• Build vs. buy for internal standards: limenet/laravel-baseline encodes "what good Laravel tooling config looks like" as executable checks rather than a wiki page. Adopting it replaces the internal baseline package/checklist most platform teams eventually write and then let rot.
• Toolchain standardization across the portfolio: Each check (Pint, PHPStan, Rector, and now config-level details) is a codified policy. Rolling it out across repos turns "please configure your tools like this" into a pass/fail CI signal, which is the difference between a guideline and a standard.
• CI cost and developer-experience roadmap: v2.18.0's hasRectorConfigWithCache check pushes teams toward enabling Rector's cache, and phpstanHasTmpDir keeps PHPStan's cache in a designated temp directory instead of polluting the repo root or getting committed. Both are small, but they compound: faster repeat static-analysis runs and fewer spurious diffs and .gitignore hacks.
• Onboarding and template repos: New services can inherit the baseline instead of a 40-line CONVENTIONS.md. Useful as an acceptance gate in a service template or a "new repo" checklist item.
• Pre-audit / pre-migration hygiene: Before a platform upgrade, a monorepo split, or a compliance review, running the baseline gives a cheap inventory of which repos have drifted from current tooling expectations.
• Drift detection over time: The fact that two new checks landed in a minor release is the core product value — the package tracks evolving best practices so we don't have to schedule that maintenance ourselves. Budget a recurring (small) upgrade cadence rather than a one-time install.

When to Consider This Package

Adopt when:

• You maintain more than one or two Laravel/PHP repos and want consistent quality tooling without bespoke scripting.
• Your standard toolchain is already in the Pint / PHPStan / Rector / Laravel family — the checks assume that world.
• You want standards enforced in CI rather than documented, and you're willing to own the occasional upgrade PR.
• You have a service template or monorepo where a single baseline definition pays for itself immediately.

Look elsewhere or skip when:

• Single application — a one-off config committed to the repo is simpler than a dependency.
• Non-Laravel or non-standard toolchain — the check set won't map to your setup.
• You already run a broader enforcement layer (GrumPHP, custom CI policy jobs, a platform-internal scaffolder) and don't want a second source of truth.
• You need runtime application features — this is a dev-only tooling/quality package, not something that ships in production code paths.
• You can't absorb frequent minor releases; the value proposition is currency, so a team that pins and forgets gets little from it.

Assessment of v2.18.0 specifically: additive and non-breaking — two new checks, no removals or config changes required. It strengthens the adoption case slightly (better CI performance and cleaner repos) but doesn't change the adoption decision.

How to Pitch It (Stakeholders)

For executives: This is a small, dev-only dependency that turns our PHP code-quality standards into automated checks instead of documents nobody reads. It's low risk — no production runtime footprint, no data handling, no vendor lock-in — and it reduces CI time and review friction across our Laravel services. Latest release (v2.18.0) added two checks that speed up static analysis and keep generated cache files out of our repos. Cost is essentially one upgrade PR per quarter.

For engineering: composer require --dev limenet/laravel-baseline, wire the check command into CI, and treat failures as the definition of "configured correctly." v2.18.0 adds hasRectorConfigWithCache (enable Rector's cache for faster repeat runs) and phpstanHasTmpDir (point PHPStan's cache at a temp dir so it stays out of the working tree and out of commits). Both are additive — no action needed beyond the version bump, though existing repos may surface new failures on first run, which is a useful backlog of small fixes rather than a blocker.