digital-creative/collapsible-resource-manager
A Filament plugin that organizes sidebar navigation into collapsible resource groups, keeping Laravel admin panels tidy as resources grow. Supports nested groups and remembers each user's open or closed state, making large apps with many resources easier to navigate.
Architecture fit. This is a presentation-layer package for Laravel Nova (v2.3.0 adds Nova 5 support) — not Filament, despite the marketplace copy. Architecturally it's a thin, non-invasive overlay: no migrations, no models, no queues, no persisted PII, no service contracts. It replaces or augments Nova's sidebar rendering, which means its blast radius is exactly the admin navigation chrome — every admin page renders it, but nothing in the data plane depends on it. For a TPM that's the key property: failure is cosmetic and revertible, not corrupting. Fit is strong only if we are on Nova 4 or 5 and have a genuine sidebar-density problem (~20+ resources across roles). If we're on Filament, fit is zero and the evaluation stops here.
Integration feasibility. Low-to-moderate engineering effort, gated on one hard constraint: only one thing may own the sidebar. If any in-house Nova::mainMenu() customization or another third-party Nova extension already touches navigation, we get duplicated menus or silent overrides. Integration is a composer require, a publish step, and a single registration site in NovaServiceProvider (tools() or mainMenu()) holding the full group→resource taxonomy. The real work is not code — it's the information architecture exercise (enumerating every resource, tool, card, dashboard, and external link and mapping it into 4–6 intent-based groups, two levels max) plus per-role QA. Estimate: 1–2 days engineering, 2–3 days IA design and role-by-role validation. The package is pure presentation, so it will not simplify permissions, search, or resource sprawl — it only reorganizes them.
Technical risk. Manageable but concentrated in dependency stewardship, not technology:
config:cache refresh on every edit; provider-defined groups evaluate per request. We should standardize on provider-driven registration to avoid a class of "my change didn't show up" incidents.Key questions for engineering before committing budget:
mainMenu() or the sidebar?Stack fit. Laravel + Nova 4 or 5. Pin exactly "digital-creative/collapsible-resource-manager": "2.3.0" (or ~2.3) — never a floating constraint — and record the minimum in composer.json with a comment. Verify the tag's own PHP/Laravel floor, since the Nova 5 bump may have raised it. Register as a Nova tool rather than mutating mainMenu() inline; that isolates the package from any existing provider customization and makes the revert a one-line removal.
Migration path. Land it behind a config flag that flips back to Nova's stock menu in one line — that's the entire rollback story and it should be documented in the PR description, not just in someone's head. Sequence:
config:clear / cache:clear / nova:publish as applicable.Content, Billing, Ops, Settings — not per Eloquent model).Compatibility. If a Nova 4 → 5 migration is in flight, do not land both changes in one PR. Upgrade Nova on the stock menu, verify, then add this package, then re-run the sidebar regression suite. v2.3.0's Nova 5 support removes collapsible navigation as a migration blocker — that's a real critical-path win — but only if the sequencing is clean, otherwise a navigation regression gets tangled with a major framework upgrade and becomes undiagnosable. A mixed Nova 4/5 estate during phased rollout is supported, which is an argument for standardizing the pattern across internal apps rather than solving it per-app.
Sequencing for standardization. If multiple Nova admin surfaces exist, pilot on one panel with the worst sidebar. Measure. Then template the group taxonomy and the regression test before rolling to the second app — the second app is where a per-app bespoke taxonomy becomes permanent inconsistency and a support burden.
Cheap regression harness. One test per role that boots Nova as that role and asserts rendered group count and first menu item. A few lines, and it catches policy regressions on the sidebar that no one will ever catch visually after a permissions change.
Maintenance. Low code surface, low maintenance velocity — the package only needs attention on Nova majors or when our resource/permission set materially changes. The real recurring cost is taxonomy governance: as resources are added, someone must place them in a group, or they vanish from the sidebar. That's an ownership question, not a technical one, and it should be assigned before adoption. Standardize on provider-defined groups so edits take effect per request and don't require a config re-cache — this removes the most common operational footgun.
Support. Internal users will file "I can't find X" tickets. Distinguish two classes up front: (a) placement problems, which this package genuinely fixes, and (b) permissions, search, or resource sprawl problems, which grouping only disguises and which will resurface as ticket volume within a quarter. Set that expectation with stakeholders before the pilot, or the package gets blamed for an IA problem it was never scoped to solve. Support burden on engineering should be near zero outside Nova upgrades.
Scaling. Scales fine along the axes that matter here: more resources mean more groups, which is what the package is for. It scales badly along two others. First, group depth — the Nova sidebar is narrow; a third nesting level becomes a maze, and the correct escape hatch is Nova search or a separate panel, not deeper accordions. Second, role proliferation — each new role is a new per-role sidebar to validate. Past roughly 4–5 distinct roles, build the group list programmatically from the authenticated user's abilities rather than maintaining declarative groups and diffing them by hand. Also watch for group headers visible to roles with no authorized children; gate that ourselves if the package version doesn't.
Failure modes, ranked by likelihood:
authorize. Debug order: is it in a group → does the role pass authorize → was config:cache cleared → is another package touching the sidebar → were assets re-published after the last Nova upgrade.nova:publish.Every one of these is cosmetic. None touches data, revenue, or customer-facing flows — but because it renders on every admin page, a broken sidebar is not low-impact for ops users mid-shift. That asymmetry justifies moving fast on adoption and still requiring a staging pass per role.
Ramp-up. Engineering ramp-up is hours, not days: one config file, one provider registration, one documented revert. The expensive ramp-up is on the product/IA side — someone has to own the grouping decision, and it should be driven by observed user behaviour (time-to-find a resource, sidebar-related ticket volume, admin task completion time), not aesthetics. Design the pilot with those three metrics and a per-role sidebar diff before flipping the flag; otherwise adoption is an opinion and the renewal decision a year from now will have no evidence behind it.
Governance recommendation. Treat this as a tactical, pinned, revertible third-party dependency and say so explicitly in the dependency policy. It's a credible buy over a 1–2 sprint hand-built Vue menu override precisely because it transfers permanent ownership of a component that must survive every future Nova major — but only if we pin the version, own the regression test, and keep the one-line fallback live. If navigation becomes a strategic differentiator (custom item types, badges, non-resource links, persisted per-user preferences), fork deliberately and budget for it; do not patch vendor code inline.
How can I help you explore Laravel packages today?