Filterable Laravel Package

Product Decisions This Supports

• Framework upgrade roadmap (Laravel 11 → 12): Release 2.1.7 removes this package as a blocker for the Laravel 12 migration. If the package sat on the critical path of the platform upgrade, that dependency risk is now cleared and the upgrade can be sequenced on its own merits rather than waiting on vendor support.
• Build vs. buy / keep vs. replace: A maintained package shipping timely framework compatibility is a signal to keep it. Sustained lag behind framework releases is usually the first trigger to evaluate an in-house replacement or an alternative — this release is evidence against replacing it.
• Dependency risk register: Downgrade this package's "maintenance risk" rating. Version 2.1.7 is a patch-level, non-breaking compatibility release, which indicates an active maintainer and a low-friction upgrade path.
• Roadmap enablement: Any planned work that assumes Laravel 12 (new LTS window, security patch cadence, access to L12 features, PHP version alignment) is no longer gated by this dependency.
• Scope check for the upgrade epic: Confirms the upgrade effort for this dependency is effectively zero engineering days — it's a composer constraint bump plus regression testing, not a code migration. Useful for sizing the overall upgrade epic and setting stakeholder expectations.

When to Consider This Package

Adopt (or retain) when:

• The product is on, or planning, Laravel 11/12 and needs the dependency to survive that upgrade without a fork or patch.
• The team wants a maintained, actively released dependency rather than owning equivalent logic in-house.
• The package's surface area is small enough that a patch-level compatibility release is sufficient — i.e., no API changes are required on our side.

Look elsewhere or re-evaluate when:

• Verify before committing: the composer illuminate/* constraint actually permits Laravel 12 (a changelog line is not proof), and the package's test matrix / CI covers L12. Also confirm transitive dependencies support L12 — a package can be L12-ready while its own dependencies are not.
• The package only supports the newest framework version and drops older ones we still run (check whether 2.1.7 narrows supported Laravel/PHP ranges — a patch release that raises a minimum version is a de facto breaking change for teams on older stacks).
• Release cadence is otherwise slow, issue response is poor, or the package is a single-maintainer project on a critical path.
• Requirements have outgrown the package and we're already wrapping or patching around it — at that point, the compatibility release is a good moment to reassess, not a reason to stay.

How to Pitch It (Stakeholders)

For executives: A dependency we rely on has released compatibility support for the latest Laravel version. This is a routine maintenance update — no new features, no breaking changes, no cost, and no work required from our team. Its practical value is risk reduction: it keeps our planned framework upgrade on schedule and removes one more item from the list of things that could delay it.

For engineering: Version 2.1.7 adds Laravel 12 support at patch level, so it should be a drop-in upgrade. Confirm the composer constraints and CI matrix cover L12 and that transitive dependencies are aligned, then fold the regression test into the existing upgrade epic rather than treating it as separate work. No code changes or migration steps are expected; if the release tightened minimum supported versions, flag it before rollout.

Ask: Approve the version bump and include it in the Laravel 12 upgrade ticket. No separate budget or roadmap slot needed.