Product Decisions This Supports
- Admin IA and navigation governance. Nova is the back-office surface for many Laravel products. Deciding which resources, tools, and cards appear in the sidebar for which roles, plans, tenants, or environments is a product decision, not a styling one. This package (by name and scope) targets exactly that: conditional hiding of Nova navigation entries.
- Role/plan-based feature exposure. Hiding a nav item is the cheapest form of gating a feature — no separate codebase, no divergent UI. Supports decisions on tiering (e.g., "Billing" visible only to owner/admin), permission models (RBAC/ABAC), and least-privilege admin access.
- Progressive rollout and soft launch. A new admin tool can ship hidden behind a flag and be surfaced per-tenant or per-cohort — useful for enterprise customers who need change control in their back office.
- Multi-tenant and white-label admin panels. Tenant-scoped navigation reduces support load and accidental cross-tenant exposure; it is also an audit/compliance talking point when admins can only see what they're entitled to.
- Build vs. buy. The package itself is archived with zero dependents, so it cannot anchor a buy decision. Its real value is as a requirements artifact: it names a recurring need ("conditional Nova nav visibility") that your team must own regardless of whether you adopt anything.
- Roadmap signal. If admin-surface hygiene keeps appearing in support tickets or security reviews, that is evidence for a small internal "admin navigation policy" capability rather than ad-hoc
if statements scattered across Nova resources.
When to Consider This Package
Consider it only as a reference implementation, not as a dependency. Concretely:
- As a dependency: no. Archived, unmaintained, last release 2023-11-04, 2 stars, 0 dependents, and the README itself redirects to maintained alternatives. That means no security patching, no Nova major-version compatibility guarantees, and no upstream support. In a Laravel/Nova stack, an abandoned package in the admin path is a supply-chain and upgrade risk disproportionate to the ~20–50 lines of logic it likely contains.
- As a design reference: yes, briefly. Worth 30 minutes to read its API shape and confirm what Nova already gives you natively (
canSee/authorizedToViewAny on resources, $displayInNavigation, Nova::mainMenu and menu-section customization, tool/card visibility callbacks, and Nova's authorization gates). Most teams find the native hooks sufficient.
- Adopt-a-fork criteria, if you insist. You must be pinned to a compatible Nova major and PHP version; you must vendor or fork the code into your repo; you must own tests, upgrades, and security review; and you must document it as internal code, not a third-party dependency. If any of those is unmet, don't.
- Look elsewhere when: you need maintained support, Nova 4/5 compatibility, multi-tenant nav policies with tests, or an auditable access-control layer. In those cases use Nova-native authorization, a maintained alternative named in the README, or an in-house trait/config map.
- Also look elsewhere if the requirement is broader than visibility — e.g., navigation ordering, search scoping, or route-level enforcement. Hiding a menu item is cosmetic; it is not authorization. Any decision here must pair visibility with server-side policy checks.
How to Pitch It (Stakeholders)
For executives (one paragraph): We evaluated a small open-source add-on for hiding items in our Laravel Nova admin sidebar. The capability is worth having — role-aware, tenant-aware admin navigation reduces support load, limits accidental data exposure, and lets us stage new admin features safely. The package is not worth adopting: it is archived, unmaintained since late 2023, has essentially no user base, and its own author points to alternatives. Buying it costs nothing but owning it costs real engineering time and carries unpatched-security and upgrade risk. Recommendation: do not add it to our dependency tree; spend a few engineering days building the same behavior on Nova's built-in authorization hooks, with tests, and treat it as internal code.
For engineering (the ask): Don't add norman-huth/nova-hide-navigation to composer.json. Instead, implement a small, tested visibility layer: a config-driven map of nav entries to roles/plans/tenants, applied through Nova resource canSee/authorizedToViewAny and Nova::mainMenu customization, with server-side policy enforcement behind every route (hiding a link is not access control). Review the package's README for the maintained alternatives it recommends and run them through the same evaluation — maintenance status, Nova major compatibility, test coverage, security cadence, dependent count — before considering adoption. If we later want a third-party option, that checklist is the gate.