Nova Menu Collapsed Laravel Package

Technical Evaluation

Architecture fit. Nova Menu Collapsed is a frontend-only micro-extension: a service provider that registers a small JS/CSS asset into Nova's menu layer and flips the sidebar's default state from expanded to collapsed. No routes, migrations, models, queues, config surface beyond a publishable default, and no outbound calls. Architecturally it is a presentation-policy default, not a capability. The decision it actually surfaces is a product one — "what should our admin navigation look like on first load for every operator?" — and the package is merely the cheapest available answer. That framing matters for a TPM: the requirement ("sidebar starts collapsed") is fully satisfiable by any implementation, so the dependency carries no lock-in and creates no architectural gravity. It should be evaluated as a UX experiment with an off-the-shelf starting point, not as a platform commitment.

Integration feasibility. High on paper, gated by environment. Adoption is one composer require stepanenko3/nova-menu-collapsed with Laravel auto-discovery — no credentials, no services, no data migration. Two gates remain: the consuming app must already run licensed Laravel Nova (paid, private Composer credentials, its own upgrade cadence), and the package must match the installed Nova major. Last release is May 2023, which places it in Nova 4.x territory; Nova 5 needs an explicit verification spike, not an assumption. The changelog is the most useful signal in the whole assessment — v1.2.2 is literally titled "Fix for new Nova version," direct evidence that this package breaks on Nova upgrades and needs a maintainer patch each time. A TPM should read that line as a forecast of recurring work, not a historical footnote.

Technical risk, ranked:

1. Abandonment risk dominates. Twelve stars, zero dependents, single maintainer, no release in over two years. There is no community validation signal and no credible expectation that a Nova 5 fix arrives. The 0.39 score is a maintenance-posture judgment, not a code-quality judgment — the source is short and readable.
2. Compatibility fragility with known failure history. Nova ships compiled, versioned frontend assets. If the package hooks a public extension point (Nova::script() / Nova::style()), upgrades are survivable; if it reaches into DOM or localStorage internals, a minor Nova upgrade can silently no-op the behavior or throw during asset bootstrap and degrade the admin panel. v1.2.2 confirms the fragility is real.
3. Blast radius is genuinely small. Realistic worst case is "the sidebar opens expanded again" for internal staff. No customer-facing surface, no PII, no secrets, no network calls, no data implications. That asymmetry — high likelihood of cosmetic regression, low likelihood of serious breakage — makes this a judgment call a TPM can carry explicitly rather than an automatic reject.

Key questions for the spike:

• Which Nova majors are actually supported, and does the default apply via a public Nova extension API or by patching frontend internals? This single answer determines whether upgrades are cheap or recurring.
• Is the default global/config-driven or per-user, and does it fight Nova's native localStorage sidebar preference — i.e., does it override a user's own expand toggle on every page load?
• Does it coexist cleanly with our other Nova extensions, or does asset registration order make the outcome non-deterministic?
• What is in-house reproduction cost? If under a day — very likely — the decision reframes from "adopt a dependency" to "own a behavior."
• Can we vendor the MIT source into a first-party package without legal or technical friction? Almost certainly yes, and that is the recommended path.

Integration Approach

Stack fit. Requires an existing Laravel app on licensed Nova, realistically Laravel 9/10 with Nova 4.x. Not a fit for Nova 5 without explicit verification, and irrelevant to any team not on Nova. Because it is frontend-only, it imposes no constraints on PHP version, database, queue driver, or hosting topology. That is precisely why it is cheap to pilot and cheap to reverse — and why it should be scoped as a UX experiment rather than a platform decision.

Migration path. Effectively none, in both directions. Adoption is one Composer require plus, at most, an optional published config; removal restores Nova's native default with zero data implications. This reversibility is the package's single strongest property and the reason a pilot is defensible despite the maintenance profile. Position it to stakeholders as a reversible experiment: the exit cost is a composer remove and a cache clear.

Compatibility. Pin the package to an exact version and pin Nova to a tested patch range in the same lockfile change; never let the package float across a Nova upgrade. Validate against the exact Nova build running in the consuming app rather than the package's documented minimum, because Nova's frontend ships compiled and "supported" is a moving target. Add a line to the Nova upgrade checklist — "verify collapsed sidebar default still renders" — so the check cannot be skipped silently during a future upgrade sprint.

Sequencing.

1. Spike, half a day. Install on a disposable branch, confirm the collapsed default renders, confirm no console errors, read the entire source (it is short). Determine global vs. per-user behavior and whether it conflicts with the native toggle.
2. Make the build-vs-buy call before piloting, not after. Given the maintenance profile and the v1.2.2 precedent, the defensible default is to treat the package as a reference implementation: copy the asset registration into a first-party Nova extension we already control, or a small internal package. That converts an abandoned external dependency into roughly a day of internal ownership — a favorable trade at this size, and it removes the governance argument permanently.
3. Pilot with a small internal admin group. Measure whether a collapsed default actually improves their workflow before standardizing. This is the product question the package exists to answer, testable at near-zero cost.
4. Roll out behind a config flag so the behavior can be disabled per environment without a deploy, and so the policy is documented and reversible rather than buried in a dependency edge of composer.json.

Operational Impact

Maintenance. Near zero in steady state, non-zero at every Nova upgrade boundary. Because the package is unmaintained, that re-validation cost lands on us permanently and cannot be delegated to a vendor roadmap. The mitigation is ownership: fork under our namespace and the external dependency disappears, replaced by a file an engineer can read in an hour. At this size, in-housing is cheaper than tracking someone else's release cadence — and cheaper than the recurring review conversation about why we depend on it.

Support. No vendor, no SLA, no security response process, no issue triage. Mitigating factors are concrete: no secrets handled, no user data touched, no outbound calls, no privileged code path. Residual concerns are supply-chain risk in the Composer graph and the governance finding that unmaintained dependencies reliably generate in review. Vendoring under MIT resolves that cleanly and pre-empts a repeat argument at the next architecture or security review.

Scaling. A non-issue. The change is a client-side default rendered once per admin session: no queries, no cache pressure, no per-request server cost beyond asset delivery. It scales trivially to any number of admin users and has no interaction with application scaling, multi-tenancy, or performance budgets. There is no scenario in which this becomes a throughput bottleneck.

Failure modes, ranked by likelihood and severity:

• Silent no-op after a Nova upgrade (likely, low severity) — the sidebar simply defaults to expanded, surfaced only by user reports. Mitigate with the upgrade-checklist line and a staging smoke test on the admin layout.
• Asset bootstrap error degrading the admin panel (unlikely, medium severity) — possible if the package patches internals rather than a public API. Mitigate by reading the source before adopting, and by shipping behind a config flag that can be flipped without a deploy.
• User preference overridden on every load (plausible, low–medium severity) — if the default ignores Nova's native toggle persistence, operators who prefer expanded navigation get fought on each page load. Verify explicitly in the spike; this is the most likely source of quiet user annoyance.
• Supply-chain compromise of an unmaintained package (very unlikely, high severity) — bounded by vendoring, which removes the attack surface entirely.

Ramp-up. Near zero for engineers already working in the Nova app: the change is a Composer require plus a line in the Nova upgrade checklist, comprehensible in under an hour. The genuine ramp-up cost is organizational, not technical — establishing the habit that someone re-verifies admin-UI defaults at every Nova major upgrade, and that the team has a stated position (fork, pin, or vendor) for low-adoption micro-dependencies. This package is a cheap opportunity to set that precedent before a higher-stakes dependency forces the same conversation under pressure. Recommendation: adopt the behavior, not the dependency — reproduce or vendor it under our namespace, pilot behind a config flag, and treat the upstream package as the reference spec.