Nova Collapsible Sidebar Laravel Package

Product Decisions This Supports

• Whether admin UX polish gets roadmap time at all. This is a chrome-level fix: reclaim ~150–250px of horizontal space on data-dense Nova screens (wide resource tables, metrics, detail forms). As a PM, the decision it informs is whether sidebar width is a measured friction point worth a sprint slot, or a cosmetic nice-to-have. Pair it with evidence — support tickets about horizontal scrolling, session recordings on 13" laptops, or a task-time baseline for your heaviest admin workflow — before it earns a slot.
• Build vs. buy vs. vendor-in. The scope is small enough that "buy" here really means "adopt and possibly own." A collapsible sidebar is a toggle, a CSS class, an icon-only state, and a persisted preference — realistically a day of work in-house against your current Nova version, and you'd control the persistence model and accessibility semantics. The package only wins if it works unmodified on your Nova version, which is the gating question below.
• Platform investment sequencing: patch Nova now vs. plan an admin migration. A 2018-era package is a datapoint about how much bespoke chrome Nova needs and how brittle that chrome is across Nova majors. That feeds the "keep investing in Nova as our admin surface, or start budgeting a replacement" conversation — not as a blocker, but as one entry in the ledger.
• Dependency risk budgeting for internal tooling. A 32-star, single-maintainer, last-release-2018 dependency is acceptable for admin-only surfaces where a regression is recoverable in hours and unacceptable anywhere customer-facing or audited. This decision is cheap to make and cheap to reverse — which is exactly the profile that makes it a good candidate for a time-boxed pilot rather than a debate.
• Defining what "remembers each user's state" must mean. The package advertises persistence but not the mechanism. Before adopting, PM should pin the requirement: per-user preference persisted server-side (consistent across devices) vs. browser-local (per device only). That single distinction determines whether the feature is a real productivity win for a multi-device admin team or a novelty.

When to Consider This Package

Consider it when:

• You are on an older Nova major (the one the package was built against, ~1.x/2.x) and want to verify quickly rather than build. This is the single biggest filter — confirm compatibility with your current Nova version before anything else, since Nova's frontend stack changed substantially in later majors (Vue 3 / Inertia / Vite), and a 2018 asset bundle is unlikely to drop in unchanged.
• The pain is real and narrow: a small internal admin team, wide tables, laptop screens, and a handful of complaints you can actually count.
• You are willing to pin the exact version, read the source, and fork or copy it in-tree if upstream goes quiet — because it already has.
• You want the keyboard toggle as a power-user affordance for a small set of daily-driver admins.

Look elsewhere — or build the 40 lines yourself — when:

• You are on a current Nova major. Verify first; assume incompatibility until proven otherwise, and treat "it installed" as different from "it behaves correctly across Nova's nav states, mobile breakpoints, and theming."
• You need accessibility guarantees (focus order, aria state on the toggle, screen-reader behavior of an icon-only strip). An icon-only nav is a known a11y risk and this package makes no claims there.
• You need branding/theming control over the collapsed strip, or responsive behavior below desktop widths — mobile nav is a different problem than a desktop collapse.
• You need support, a security disclosure path, or a maintainer with a bus factor above one.
• Sidebar width is one of several admin UX issues. Solving one 200px problem in isolation, on an unmaintained dependency, is a poor trade against a broader admin-UX pass.

How to Pitch It (Stakeholders)

To executives: This is a small, free, contained UI tweak that gives our admin users back horizontal screen space on their busiest screens, and it remembers each user's preference. Blast radius is limited to the admin panel; nothing customer-facing is touched. The catch is maturity — it is a pre-1.0 package with a single maintainer and no releases since 2018 — so I'm recommending a short, time-boxed pilot on internal admin screens, not a platform commitment. Cost is essentially the engineering hours to validate it against our Nova version; if validation fails, the fallback is building the equivalent ourselves in about a day.

To engineering: Treat this as an evaluation build, not a stable dependency. Three things before we pilot: (1) confirm it works on our Nova major — the frontend stack moved on since 2018 and I expect friction; (2) tell me how the collapsed state is persisted, DB-backed per user or browser-local, because that changes the user-facing promise; (3) tell me what the icon-only state does to keyboard focus and screen readers. If it passes, pin the exact version, wrap it behind our own layout/asset integration so replacing it is a one-file change, and be prepared to vendor the source in-tree — the only changelog entry is a single keybinding bug fix, which tells us the project is (was) alive but gives no signal about direction or support. Assume we own the fork.