Qa Tooling Wrapper Laravel Package

Product Decisions This Supports

• Build vs. buy on internal QA toolchain assembly: This package is essentially a metapackage — a curated dependency bundle (PHPStan, PHP-CS-Fixer, Rector, Psalm-adjacent tooling, Composer normalization, etc.) that you would otherwise hand-assemble in every repository's require-dev. The build-vs-buy question it answers is "do we maintain our own dev-tooling manifest, or adopt a maintained one?"
• Standardization of CI quality gates: Informs the decision to enforce a single PHP-static-analysis and style baseline across a monorepo or fleet of Laravel services, rather than letting each team pin its own tool versions.
• Dependency-hygiene strategy: The wrapper exists specifically to break circular dependencies between test-utilities and extension packages (e.g. phpstan-no-safe). That is a real architectural pattern — a "tooling BOM" (bill of materials) layer — that a platform/DevEx team can reuse to keep their internal packages acyclic.
• Adoption of the surrounding Makefile-driven dev workflow: wyrihaximus/makefiles + this wrapper implies a standardized make qa surface. This feeds decisions on onboarding time, local/CI parity, and whether to invest in a Makefile-first developer experience versus Composer scripts or Docker-only.
• Extension-point decisions: If we want custom PHPStan rules or Rector sets as first-party packages, this package is the template for how to publish them without pulling the entire test suite into every consumer.
• Roadmap / platform-team scoping: Useful as a reference implementation when designing an internal "dev-tooling" package for our own Laravel estate; low direct value as a dependency.

Key caveat for decisions: 0 stars, 0 dependents, and a single-maintainer authorship mean this is not a supply-chain recommendation. Treat it as design inspiration and a pattern to assess, not as a production dependency to adopt unvetted.

When to Consider This Package

Consider it (or its pattern) when:

• You maintain multiple PHP/Laravel repositories and are tired of drift in PHPStan levels, Rector rule sets, PHP-CS-Fixer configs, and Composer normalization across them.
• You already lean on (or are willing to lean on) wyrihaximus/makefiles — the two are designed together and the wrapper's value is largely realized through that workflow.
• You are building extension packages that need static-analysis tooling but must not depend on your test utilities for acyclic reasons. This is the specific problem the wrapper solves.
• You want a low-friction proof of concept for a "tooling BOM" in a non-critical or internal-only project, where the risk of an unmaintained dependency is acceptable.
• You are evaluating the design, not the dependency: reading this repo is a fast way to understand how to structure a QA metapackage without circular deps.

Look elsewhere when:

• You need a vetted, widely-adopted dependency. Zero stars and zero dependents fail standard vendor-risk thresholds; there is no community signal, no security review trail, and bus-factor is one.
• Your stack is Laravel-specific and opinionated rather than framework-agnostic PHP. There is no Laravel integration here — no Artisan commands, no config publishing, no service provider. Laravel teams typically get the same outcome from larastan, Pint, and a shared composer.json snippet.
• You want granular version control over individual tools. A wrapper pins/bundles the set; teams that need to run PHPStan 1.x while another repo runs 2.x will fight it.
• You require long-term support guarantees, SLA, or a commercial owner. MIT + single maintainer + releases dated into the future (2026-10-06) is unusual metadata worth verifying before any commitment.
• Your organization already has a platform/DevEx package doing this job — adopting a second tooling bundle creates more drift, not less.

How to Pitch It (Stakeholders)

To executives (30 seconds):

This is a small, single-maintainer open-source utility that bundles PHP quality-checking tools into one installable package. It is not a system we need to buy or license — it is MIT-licensed and free. Its value to us is as a blueprint: it demonstrates a clean way to standardize code-quality tooling across many services without duplicating configuration or creating circular dependencies. I recommend we study the pattern, not adopt the package itself, given its zero adoption and single-maintainer risk. No budget request; a small platform-engineering spike if we want to build our own equivalent.

To engineering leadership / architects:

The wrapper solves a real, specific engineering problem: keeping QA tooling shared across packages without forcing every extension package to depend on the test-utilities package (which creates dependency cycles and bloats production-adjacent installs). It ships as a dev-only metapackage — one line in require-dev gives a consistent PHPStan / fixer / normalizer baseline. It pairs with a Makefile-driven make qa workflow, which is attractive for local-CI parity. The tradeoffs are real: no Laravel integration whatsoever, no adoption signal (0 stars, 0 dependents), a single maintainer, and coarse version control — you take the whole tool set or nothing. Recommendation: use it as a reference architecture for an internal tooling BOM; do not add it to our dependency graph without a fork-and-own decision.

To the engineering team (practical framing):

If we were going to write our own acme/dev-tooling metapackage, this is the structure we'd copy — thin wrapper, dev-only, no runtime footprint, no Laravel coupling, composed so extension packages can require the tooling without requiring the test suite. The gap is that it gives us nothing Laravel-native (no larastan wiring, no Pint) and we'd own the maintenance anyway. Worth a half-day spike to see whether a fork gets us to a standardized make qa across our services faster than assembling it ourselves.

Honest one-liner: Great pattern, weak package — borrow the idea, not the dependency.