Dev Tools Laravel Package

Product Decisions This Supports

• Build vs. buy for developer tooling: soyhuce/dev-tools is a dev-only dependency that packages an opinionated QA baseline (code style, static analysis, refactoring presets) for Laravel projects. Adopting it replaces the in-house "copy the config files from the last repo" pattern that quietly rots across a portfolio of apps.
• Roadmap: framework upgrade readiness: release 4.1.0 runs the package's own test suite against Laravel 12. That is a compatibility signal, not a feature — it lets you treat this package as a non-blocker in a Laravel 12 migration plan, and it gives you a concrete date-stamped data point for the "are our dev dependencies ready?" checklist.
• Feature work vs. platform work: adopting the package shifts effort away from maintaining lint/static-analysis plumbing and toward product work. The trade-off is explicit: you accept upstream defaults and their release cadence.
• CI quality-gate standardization: a shared toolchain means one CI job definition and one set of failure semantics across services, which makes "definition of done" and PR review expectations uniform — useful when multiple squads or contractors touch the same codebase.
• Onboarding and time-to-first-PR: new engineers inherit working tooling on day one rather than learning a bespoke, undocumented setup.
• Use cases: agencies or product orgs running several Laravel apps/packages; teams without a dedicated DevEx/platform engineer; package authors who want their libraries held to the same standard as their apps.

When to Consider This Package

Adopt when:

• You maintain more than one Laravel application or package and want a single, versioned source of truth for code quality tooling.
• You have no dedicated platform/DevEx owner, and the alternative is configs drifting per repo.
• You want static analysis and style enforcement to be default-on rather than a per-project negotiation.
• You are planning or executing a Laravel major-version upgrade and need to know your dev dependencies track framework releases (4.1.0 confirms Laravel 12 test coverage).
• Your team is comfortable with the maintainer's opinions; you are buying defaults, not a configurable framework.

Look elsewhere / stay in-house when:

• You have a single small application — the coordination benefit approaches zero and you inherit an extra dependency for marginal gain.
• You need rules the package does not express, or you have strong existing conventions (custom rule sets, strict baselines) that would be fought rather than supported.
• You need framework-agnostic tooling (non-Laravel PHP, or a mixed stack).
• Your risk model penalizes small-maintainer dependencies in the critical path. Note this is a dev-only dependency — it does not ship to production, which materially lowers blast radius — but it can still block CI and therefore block releases.
• You require a published support/deprecation policy. A "tests pass on Laravel 12" changelog entry is a compatibility signal, not a contractual support commitment; if you need LTS-style guarantees, negotiate that expectation internally or vendor/pin.

Adoption hygiene: pin to a minor version, treat upgrades as routine but reviewed changes, and keep an escape hatch (local override config) so a bad upstream release is a config change, not an incident.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a developer-tooling package, not a runtime dependency — it never ships to production, so it carries no customer-facing risk. It gives every Laravel codebase the same automated quality checks, which means fewer review cycles, faster onboarding, and less drift as the portfolio grows. The 4.1.0 release is a maintenance release that confirms it works with Laravel 12, so it will not hold up our framework upgrade. Cost is a dev dependency and a small amount of process discipline; the alternative is continuing to maintain the same configuration by hand in every repository.

For engineering leads: Version 4.1.0 is a low-risk maintenance release — it adds Laravel 12 to the test matrix and contains no breaking changes, no new features, and no deprecations. It is safe to take on a patch/minor bump. The strategic point is what it buys us: a single versioned, CI-enforced baseline for code style and static analysis across services, so quality gates are identical everywhere and upgrades are a dependency bump rather than a config migration. Recommended posture: adopt where we run more than one Laravel codebase, pin the minor version, and keep local overrides available so upstream surprises are a one-line fix. Where we have strong bespoke conventions, don't force it — the value is uniformity, and forcing it would produce the opposite.