Nova Collapsible Groups Laravel Package

Technical Evaluation

Architecture fit — poor for anything current. nova-collapsible-groups is a Nova 2-era theme patch. Its mechanism is almost certainly asset injection (Nova::script() / Nova::style() in a service provider, or published overrides of public/vendor/nova/app.{js,css}) that adds collapse/expand behaviour to the sidebar navigation groups rendered by Nova's core Vue theme. That architecture is tightly coupled to Nova 2's compiled, non-modular front end. Nova 3 reworked the asset pipeline; Nova 4+ rewrote the UI on Vue 3 + Inertia with a first-party menu API and, critically, native collapsible navigation groups. The package's entire reason for existing was absorbed into the product it patches.

Integration feasibility — mechanically trivial, strategically pointless. composer require tanmuhittin/nova-collapsible-groups plus php artisan vendor:publish is a five-minute task on a Nova 2 install. The problem is not effort, it is target: the package has one meaningful consumer profile (a Nova 2.x application that intends to stay on Nova 2.x), and that profile is itself a liability.

Technical risk — high, concentrated in three places.

Key questions before any decision:

1. What Nova major version is actually deployed? If ≥ 4, this package is redundant and should be rejected outright.
2. Does the team intend to upgrade Nova within the planning horizon? If yes, the integration work is throwaway.
3. Is the business requirement genuinely "collapsible groups," or is it "find things faster in a growing sidebar"? The latter has cheaper first-party answers (menu ordering, grouping, global search).
4. Can we accept owning a forked asset bundle with no upstream, or is there appetite to vendor a 50-line JS snippet behind our own service provider?
5. Does the admin run under a CSP that would block inline/dynamically injected scripts?

Recommendation: reject as a dependency. If a legacy Nova 2 install genuinely needs this behaviour, vendor the logic into first-party code rather than taking a dependency on an abandoned theme patch.

Integration Approach

Stack fit. Package targets ~Laravel 5.6–5.8 / PHP 7.1–7.3 / Nova 2.x. Modern Laravel (10/11/12) + PHP 8.2+ + Nova 4/5 is outside its design envelope. Treat it as incompatible until proven otherwise by a spike, not the reverse.

Migration path.

• On Nova 4/5: no migration. Enable native collapsible navigation groups and retire the requirement. This is a documentation change, not an engineering one.
• On Nova 3: evaluate the native menu API first; Nova 3's menu customisation is far more capable than Nova 2's, and a small first-party menu class is likely sufficient.
• On Nova 2 with a hard constraint: copy the relevant JS/CSS into our own Nova service provider (or a private Composer package under our namespace), pin the assets, and add a smoke test that renders the Nova dashboard. Do not depend on the public repo.

Compatibility gates. Before any pilot, verify in a throwaway environment: Composer resolves without --ignore-platform-reqs; assets publish to the expected path; sidebar renders on the Nova dashboard, a resource index, and a detail page; no console errors; behaviour survives nova:publish and a composer update of laravel/nova.

Sequencing (if pursued at all):

1. Confirm Nova version and upgrade roadmap — gates everything downstream.
2. Confirm the UX requirement with the actual admin users; check whether native/search-based discovery already satisfies it.
3. If native is insufficient and Nova is pinned ≤ 3, allocate a short spike (≤ 2 days) to fork-and-vendor.
4. Ship behind a config flag so it can be disabled without a deploy.
5. Add the vendor bundle to the upgrade checklist for the eventual Nova upgrade.

Operational Impact

Maintenance. Effectively 100% ours. No upstream commits, no issue responses, no PHP/Nova compatibility releases. Budget for re-validation on every Nova upgrade, every PHP minor, and every admin asset rebuild. This is a permanent small tax for a small cosmetic win.

Support. No vendor. Support requests route to the internal team, and the failure symptom ("the admin panel is blank") is high-urgency by default, so a cosmetic package inherits P1 expectations it cannot justify.

Scaling. Negligible runtime cost — it is client-side DOM toggling on a menu that is already rendered. It does not touch queries, queues, or request handling. The scaling concern is organisational, not technical: the sidebar grows as the app grows, which is precisely why the native solution keeps improving and this one does not.

Failure modes to instrument.

• Nova upgrade or asset republish silently reverts the behaviour (cosmetic regression, low signal — add a visual check to release QA).
• Injected JS throws and blanks the Nova SPA (high severity — needs a documented one-line rollback, i.e. the config flag).
• CSP violation blocks the toggle; behaviour degrades to "always expanded" (acceptable) or errors (not).
• PHP/Nova version constraint mismatch blocks composer install during an emergency deploy — the worst possible time to discover a dead dependency.

Ramp-up. Low skill cost (any Laravel developer understands Nova asset registration) but non-zero context cost: whoever owns it must understand Nova's theming internals well enough to debug breakage after an upgrade, and that knowledge expires with Nova 2.

Bottom line. This package solves a problem the framework now solves natively, on a version of the framework almost nobody runs, with no maintenance since 2019 and zero downstream validation. The only defensible use is a short-lived fork inside a Nova 2 estate that is explicitly frozen — and even there, the honest answer is a first-party snippet, not a dependency.