Product Decisions This Supports
- Build vs. buy vs. configure: The core decision this package forces is triage, not procurement. It solves "our Nova sidebar has 30+ resources and is unusable" — a real, recurring admin-IA problem. But because the capability shipped natively in Nova 1.0.18, the correct decision is configure, not buy: set
public static $group on resources and let Nova render collapsible sections. Treat the package as a data point that the platform vendor validated the need, not as a dependency.
- Admin information architecture as a first-class feature: If your product ships a Nova-based back office to internal ops, CS, or tenant admins, sidebar grouping is a UX decision on par with any customer-facing navigation. This package is evidence that resource sprawl is a predictable failure mode past roughly 15–20 resources — plan grouping conventions before the sidebar degrades, not after.
- Roadmap/upgrade gating: The deprecation notice is a hard constraint. Any roadmap item that assumes this package implies pinning Nova below 1.0.18 and freezing framework upgrades. That trade is almost never worth it for a feature you can get for free by upgrading — it belongs in an "upgrade debt" line item, not a feature line item.
- Segmentation-driven nav: Grouping by domain (Billing, Catalog, Support, Settings) or by persona (Support tools, Admin tools) is a cheap way to make a single Nova install serve multiple teams. This is useful signal when deciding whether to build one shared admin or role-scoped variants.
- Use cases where it applies: large CRUD-heavy internal tools; multi-tenant admin panels with many resources; permission-gated navigation where only a subset of groups is visible per role; migration of a sprawling "everything on one screen" admin into a curated one.
When to Consider This Package
- Only for legacy estates pinned to Nova versions before 1.0.18, where a native upgrade is genuinely blocked (heavily forked Nova internals, custom tooling coupled to old APIs, or a maintenance-only product under change freeze). Even then, prefer vendoring a private fork over a transitive dependency on an abandoned 2018 package.
- Never for new builds. Last release November 2018, [DEPRECATED] in the description, 42 stars, no compatibility guarantee against Nova 2/3/4+. Adopting it means owning PHP compatibility, Nova internals drift, and Laravel upgrade breakage with zero upstream support.
- Look elsewhere — specifically, to Nova's built-in
$group property and menu/section primitives — whenever the requirement is: collapsible sidebar sections, ordering, icons, per-user or per-role group visibility, or dynamic grouping driven by config. The native path removes the dependency entirely and survives upgrades.
- Signals that you should not adopt: the requirement is achievable with a few static properties (it is); you can't name an owner for a fork; your Laravel version is newer than the package was ever tested against; or the "benefit" is cosmetic sidebar collapse that Nova already renders.
- Reasonable non-code use: read its README and issue threads as lightweight user research on how teams actually group resources — useful for naming conventions and defaults, not for shipping code.
How to Pitch It (Stakeholders)
Bottom line: do not adopt this package. Adopt the capability. alexbowers/nova-categorise-resources addressed a genuine problem — Nova admin sidebars become unnavigable as resources multiply — but it is explicitly deprecated, last shipped in 2018, and its entire functionality was absorbed into Nova 1.0.18 as built-in resource grouping. It is a shim for a gap that no longer exists.
For executives: This is a "no purchase, small scope" recommendation. The user-facing benefit — a tidy, collapsible, grouped admin sidebar — is deliverable through configuration on a supported Nova version. We get the outcome with no new third-party dependency, no security surface, and no maintenance burden. If we are currently below Nova 1.0.18, the ask is a version upgrade, not a package integration; that upgrade is the work item, and it retires other legacy risk at the same time.
For engineering: Do not add this to composer.json. Implement grouping with public static $group on resources and Nova's native menu sections; if we need per-role visibility or custom ordering, that is a small amount of application code we control, not an abandoned vendor package. If any branch still references it, remove it and file the Nova upgrade as the tracking ticket. Cost of ownership for the package is unbounded — PHP/Nova compatibility breaks land on us with no upstream fix — while cost of the native route is a few lines and a version bump.
Risk of inaction: low today, rising with every framework upgrade. Risk of adopting: ongoing, unbounded, and entirely avoidable.