Support Laravel Package

Product Decisions This Supports

• Framework upgrade planning: 0.2.0 widens the constraint to illuminate/support ^13, which makes this package a viable dependency for teams planning a Laravel 13 upgrade. This directly informs whether the package can stay in your dependency graph through the next major framework cycle, or whether it becomes upgrade debt to be forked, replaced, or dropped.
• Build vs buy for shared utilities: A small "support" package occupies the same slot as the helper traits and base classes teams tend to accumulate internally. Adopting it lets you retire in-house utility code and the maintenance burden that comes with it — a decision worth revisiting now that the package is actively maintained across framework versions.
• Roadmap sequencing: The 0.1.x → 0.2.0 jump is dominated by tooling and compatibility work (Pest mutation testing, type-coverage workflows, Laravel 13 allowance) rather than new features. Treat this as a stabilization signal: safe to adopt for stability-sensitive work, but do not plan product features on top of it expecting new capabilities.
• Risk and exit-cost assessment: Because the package is narrow and utility-scoped, the blast radius of a future breaking change or abandonment is contained. That lowers the cost of a "try it and see" decision versus a framework-adjacent package that would touch routing, auth, or persistence.
• Quality-signal input to vendor/OSS evaluation: The investment in mutation testing and type-coverage indicates the maintainers are measuring test effectiveness, not just test presence. That is a reasonable proxy for defect risk when comparing this package against alternatives with thinner CI.

When to Consider This Package

Consider it when:

• You are on, or planning, a Laravel version whose illuminate/support constraint is satisfied by ^13 — verify the exact lower bound against your current framework version before committing, since the notes describe the upper end of the range, not the floor.
• You have duplicated internal helper/trait code with no clear owner and want a maintained external home for it.
• Your team values visible quality engineering (mutation testing, type coverage) as a selection criterion for third-party dependencies.
• You need a low-coupling dependency — utility packages are easy to wrap behind a thin internal adapter and easy to remove later.

Look elsewhere when:

• You need guarantees this project does not advertise: no security policy, SLA, or long-term support commitment is evident from the release notes.
• Your framework version falls outside the supported range and you cannot wait for a constraint bump — pin an older release and track upstream, or implement the handful of helpers internally.
• Your risk tolerance requires a broad maintainer base. A single-maintainer package with frequent refactors and pre-1.0 versioning means breaking changes are plausible on any minor bump.
• You need behavioral stability across patch releases in a regulated or safety-critical path; a 0.1.6 → 0.2.0 minor bump that includes refactors is a signal to pin exact versions.

Adoption guardrails: pin to an exact version, wrap usage behind an internal adapter, and add a scheduled check for new releases so constraint bumps are evaluated deliberately rather than discovered during an unrelated composer update. Note that 0.2.0 changes only dev tooling and the framework constraint — no runtime API change is described — so a re-test of your integration is cheap but should not be skipped, given the refactor in the same release.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk infrastructure dependency that keeps our Laravel stack current. The latest release adds support for the next major Laravel version, which removes a potential blocker from our upgrade roadmap and reduces the chance we get stuck on an unsupported framework. Cost of adoption is minimal and reversible; the main risk is that it is a single-maintainer, pre-1.0 project, which we mitigate with version pinning and an internal wrapper.

For engineering: 0.2.0 bumps illuminate/support to allow ^13 and refactors the test tooling to use Pest mutation testing with type-coverage workflows — no runtime API changes are described. Treat it as a compatibility release: worth taking to keep us upgrade-ready, but pin the version, since pre-1.0 minor bumps can carry refactors. If you are already on a version below the new range's floor, confirm the lower bound before bumping, and run the integration suite rather than assuming a tooling-only change is inert.