Categorise Resources Laravel Package

Technical Evaluation

Architecture fit

• Scope is narrow and well-defined: group Nova resources into collapsible sidebar categories. This is a UI/menu-layer concern, typically implemented as a Nova tool or an override of Nova's menu bootstrapping — a small surface area, likely a handful of classes plus a service provider.
• Fit is conditional on two things: (a) the application uses Laravel Nova at all, and (b) it is on a Nova version that lacks native menu grouping. Nova 4 introduced Nova::mainMenu() with MenuSection/MenuItem, which delivers this capability natively. On Nova 4+, this package is functionally redundant.
• The package solves a real, recurring Nova pain point (sidebar sprawl as resource count grows past ~15–20), but it is a developer-experience feature, not a business-logic dependency. It belongs in the "internal tooling" tier, not the critical-path tier.

Integration feasibility

• composer require from Packagist is trivial if constraints resolve. Last release 2020-09-23 implies PHP 7.x-era constraints (illuminate/support ^6|^7, nova ^2|^3 likely). On Laravel 10/11 or Nova 4/5 this will almost certainly fail resolution or emit deprecation noise.
• Nova itself ships from a private Composer repository (nova.laravel.com) requiring credentials in CI and in every developer environment. Any dependency that pins Nova versions adds friction to Nova upgrades — a commercial, license-gated upgrade path you don't control.
• Verdict: feasible as a fork/vendored copy, not as a live upstream dependency.

Technical risk

• Abandoned upstream (high): archived repo, zero dependents, 4 stars, single-release history. There is no maintainer to patch a Nova compatibility break.
• Version drift (high): the package hooks Nova menu internals, which are not a stable public API across majors. Silent breakage on Nova upgrade is the primary failure mode — the menu simply renders wrong rather than throwing.
• Bounded blast radius (mitigating): MIT license plus a small code footprint means the code is fully auditable and cheap to reimplement or absorb in-house. This is the package's only real asset.
• Supply chain (low–medium): archived repos can be deleted or unlisted; depend on a commit hash or vendor the source rather than relying on a floating dev-master.

Key questions

1. Which Nova version is in production, and is an upgrade to Nova 4+ (native menu sections) on the roadmap within 2 quarters?
2. What exactly does the package override — service provider boot, NovaApplication, or a registered tool? Is it conflict-prone with other menu-customizing packages?
3. Are there tests, and does the code pass on PHP 8.1+ with declare(strict_types=1) and current Laravel?
4. How many resources exist today, and what is the projected count in 12 months? (Below ~15, grouping yields little.)
5. Do we have an internal Composer registry (Satis/Private Packagist) to host a fork?

Integration Approach

Stack fit

• Only relevant to a Laravel + Nova stack. Zero value outside Nova; no applicability to Blade/Livewire/Filament admin panels.
• Best-fit pattern: absorb the concept, not the dependency. Either adopt Nova 4's native MenuSection API, or fork the package into an org-namespaced internal package.

Migration path

• Path A (preferred): Upgrade/target Nova 4+ and implement grouping via Nova::mainMenu() in NovaServiceProvider. No third-party dependency, no abandonment risk, supported upgrade path.
• Path B (fallback): Fork the MIT source into internal/nova-resource-categories, relax Composer constraints to current PHP/Laravel/Nova, add a smoke test that asserts menu structure renders, publish to an internal registry.
• Path C (avoid): Direct composer require marshmallow/categorise-resources. Only defensible for a short-lived spike or a legacy Nova 3 app in maintenance mode.

Compatibility

• Gate the decision on a composer why-not probe against the current lockfile before any design work. If resolution fails on the first attempt, skip straight to Path A/B — do not spend time patching an unmaintained fork unless Path A is blocked.
• Confirm the package's Nova constraint explicitly; Nova 5 compatibility is implausible given the 2020 release date.

Sequencing

1. Inventory: Nova version, resource count, existing menu customization, other Nova tools in use (half-day).
2. Spike native Nova 4 menu sections against a representative resource set (1–2 days).
3. Decision gate: native sufficient → close; insufficient → fork budget.
4. Fork/vendor: update constraints, add menu-rendering test, publish internally (2–3 days).
5. Cutover in a non-production environment; verify no conflict with other menu customizers.

Operational Impact

Maintenance

• Upstream maintenance is effectively zero. The moment the package is installed, ownership transfers to your team in full. Budget for at least one engineer-day per Nova major upgrade to re-validate menu behavior, whether forked or native.
• Native Nova 4+ removes this cost entirely and is the strongest argument against adoption.

Support

• No vendor support, no security response process, no issue triage. Internal escalation only. For a sidebar-grouping feature this is tolerable; it would be disqualifying for anything touching auth, data, or payments.

Scaling

• Not a runtime scalability concern — it affects admin navigation, not request throughput or query load. Real scaling dimension is resource count: the feature's value grows nonlinearly with the number of registered Nova resources and becomes genuinely valuable above ~20.
• Secondary scaling dimension is team size: better-organized admin navigation measurably reduces onboarding friction for new engineers and support staff navigating the back office.

Failure modes

• Composer constraint conflict on modern PHP/Laravel — loud, caught at install.
• Silent menu breakage after a Nova upgrade — quiet, caught only by manual QA. Mitigate with a menu-structure smoke test.
• Boot-order conflict with another package that also overrides the Nova menu — causes missing or duplicated entries.
• Upstream repo deletion / Packagist unlisting — mitigated by fork or commit-hash pinning.
• Maintainer absence during an urgent Nova patch window — no fix available.

Ramp-up

• Near-zero for any engineer already fluent in Nova service providers; the code is small enough to read in an afternoon.
• Realistic adoption cost is the decision overhead, not the integration: expect 3–5 engineer-days end-to-end for the fork-and-harden path, versus ~2 days to validate and ship the native Nova 4 approach.

TPM recommendation: Do not take a production dependency on this package. The low score (1.225), archived status, zero dependents, and 2020 release date all point the same direction, and Nova 4's native menu sections supersede the functionality. Treat the repository as a reference implementation — read it, then reimplement natively or fork under MIT. The genuine opportunity value here is the validated product insight (Nova sidebar sprawl is real), not the code.