Active Laravel Package

Product Decisions This Supports

• Re-opening a closed build-vs-buy decision. The prior assessment concluded vendor or replace, not adopt, anchored on three signals: archived: yes, last release: 2022-03-10, and dependents: 0. A 9.0.0 release is direct evidence that at least one of those signals is now stale. The live decision is no longer "vendor it"; it is "re-verify the maintenance posture before we spend the sprint vendoring." That re-verification is cheap (minutes) and the wrong call is not (either we vendor code we didn't need to own, or we adopt a package we can't trust).
• Reading a major version bump with no notes as a governance signal. The 9.0.0 release ships with no published release notes. That is itself decision-relevant data, and it cuts both ways: a major bump implies breaking changes we cannot scope, and empty notes imply release hygiene below the bar we'd want from a dependency on an upgrade path. Treat "unknown contents" as unassessed risk, not no risk — do not let the version number alone flip the decision.
• Dependency policy and upgrade-path planning. This remains the strongest argument in the file. An actively released package is still a recurring line item on every Laravel major upgrade, and a major-versioned one adds the possibility of its own breaking changes layered on top. The roadmap question is unchanged in shape: do we want a third-party helper owning "where am I" logic, or a small owned module? Only the cost of the answer moved.
• Accessibility roadmap. Independent of maintenance status, class-only active state is a visual affordance; WCAG wants a semantic one (aria-current="page" / aria-current="true"). Any 9.x adoption still requires us to decide whether active state is a CSS class, a semantic attribute, or both — and to make that a shared contract rather than 40 hand-rolled conditionals. This decision must not be deferred on the basis of the release being new.
• Design-system coupling. The helper returns a styling artifact (a class name). The product decision is whether active state is a token the front end owns (.is-active, [aria-current]) or a literal string scattered through Blade. Cheap to fix now, expensive after 200 templates — and unchanged by any release.
• Multi-context and role-scoped navigation. Admin vs. public vs. tenant-scoped menus need wildcard/parent-trail matching (admin.*, settings.*) so a child page keeps its parent section highlighted. Route-pattern matching remains the lever for that UX decision — and for scoping how far matching logic grows before it becomes a homegrown router. A 9.0.0 major could plausibly change these matching semantics; assume it might until proven otherwise.
• Feature-level use cases it unblocks cheaply: sidebar sections, tab bars on record detail pages, wizard/step indicators, docs/changelog navigation, "you are here" affordances in long settings trees.
• Opportunity signal. Unchanged: teams keep re-implementing active-state logic. The takeaway is still standardize the pattern internally; the open question is only whether this package or our own module is the vehicle.

When to Consider This Package

Verification gate (do this first — it supersedes the criteria below): Because 9.0.0 shipped with empty release notes, confirm before any decision: (1) is the repository still archived, or has maintenance resumed; (2) what the 9.0.0 changelog actually contains — breaking changes, minimum PHP/Laravel, renamed APIs; (3) current dependent count and issue-response activity; (4) whether a 9.x support/security-patch posture exists. Until (1)–(4) are answered, hold the "vendor it" recommendation.

Consider it when:

• The verification gate clears — repo is maintained (or at minimum versioned deliberately), and 9.0.0's breaking changes are documented and scoped.
• You are on a Blade-rendered, server-side Laravel app with conventional named routes and want nav highlighting via a one-line helper instead of repeated request()->routeIs() conditionals.
• You need route-pattern, action, or URL matching with wildcards — parent-section highlighting across a route group — expressed once rather than in every layout.
• You need semantic (aria-current) output or configurable state tokens and 9.0.0 supplies them; that would materially change the calculus in the package's favour.
• You treat it as a reference implementation: read the source, extract the matching logic you need, own it.

Look elsewhere (or build the 20-line version) when:

• 9.0.0's notes stay empty and the archive status is unconfirmed — an unsupported major release with undocumented breaking changes is a worse position than a stable archived one. Revert to vendor-or-replace immediately.
• You are on Laravel 10/11/12 or PHP 8.2+ and the new major doesn't explicitly declare support; request()->routeIs(), Route::is(), and @class cover most of the same ground natively.
• Your UI is Inertia, Livewire, or a JS framework — the client-side router owns active state.
• You require aria-current semantics and the new major doesn't provide them; you'll be wrapping or rewriting output anyway.
• You have a dependency governance or SBOM policy and 9.0.0 has no release notes, no security-patch stream, no support SLA.
• Route matching is starting to encode authorization or visibility rules — that belongs in middleware/policies, not a nav helper.

Adoption criteria, in short: Gate cleared + Blade + named routes + supported framework line + documented breaking changes = reasonable. Gate unclear = hold. Anything else = lift the logic, drop the package.

How to Pitch It (Stakeholders)

For executives: A new major version (9.0.0) of this utility shipped, which invalidates the headline of our last review — we had it recorded as archived and unmaintained since 2022. We are not recommending adoption on the strength of a version number. The release arrived without notes, so we cannot say what changed or what it breaks, and a major bump can mean anything from a rename to a rewrite. The business-relevant facts are unchanged: this is a tiny, MIT-licensed helper answering one question — "which nav item is the user on?" — and it is not a platform bet. The decision is paused for a short verification (confirm maintenance status and read the changelog), after which we either adopt a maintained package or spend well under a developer-day vendoring the matching logic and dropping the dependency. Either outcome is cheap; what we will not do is let an undocumented major release enter the stack on the assumption that "newer is better." Expected cost to resolve: under a day. Expected benefit: one fewer unowned dependency gating framework upgrades, plus a consistent, accessible "you are here" treatment across the product.

For engineering: 9.0.0 is published with empty release notes. Do not upgrade blind. Actions, in order: (1) confirm whether the repo is still archived and whether 9.0.0 is a real maintenance resumption or a one-off tag; (2) pull the changelog/diff and enumerate breaking changes, minimum PHP/Laravel, and any API renames; (3) re-check dependents and issue activity to gauge whether 9.x will be supported forward. If it clears: upgrade behind a pin, and vendor our wrapper so the package's surface stays narrow — app/Support/ActiveState, configurable token output plus aria-current, tests covering wildcard/parent-trail and multi-tenant route prefixes. If it doesn't clear: extract the matching logic from the pinned source, add the same tests, remove the Composer dependency. Either path, pair it with a one-time sweep removing ad-hoc routeIs() conditionals from Blade so there is one source of truth.

For design/product: Nothing about the design decision changes with this release. The upside is still consistency — every nav, tab bar, and settings sub-menu behaving the same, including parent-section highlighting on child pages — and it only lands if we define active state once: a token (.is-active / [aria-current]) that design owns, not a literal class string sprinkled through templates. The one product-facing caveat: if 9.0.0 changed how states are emitted, we should confirm the contract with engineering before designers spec against it. Otherwise this remains a low-cost opportunity to make navigation legible and accessible without new headcount or new tooling.