Nova Fixed Bars Laravel Package

Technical Evaluation

Architecture fit. cloudcake/nova-fixed-bars is a micro-package that does one thing: pin the Nova sidebar and/or header bar in place via CSS overrides delivered through Nova's asset pipeline. Architecturally it is a thin service provider plus a published stylesheet, registered through Nova's Nova::script/Nova::style hooks or a custom tool. It introduces no routes, no database migrations, no queues, and no server-side behaviour. That is a genuinely low-blast-radius shape: it composes with a standard Laravel + Nova application without touching domain code. The cost is equally structural — the package's entire value is a handful of CSS selectors targeting Nova's internal markup and utility classes, which means its correctness is coupled to Nova's compiled frontend rather than to any stable contract.

Integration feasibility. High mechanical ease, low durability. Installation is a single Composer require and a provider registration, with an optional config publish to select fixed sidebar, fixed header, or both. There is no meaningful wiring into application code, so a proof-of-concept can be stood up in under an hour. The feasibility question is not "can we install it" but "does the CSS still match the Nova version we're on." The last release is January 2020, which places it in the Nova 2 era; Nova 3 and later moved to a different Tailwind configuration and, more importantly, Nova 4 and 5 substantially reworked the layout shell and shipped a first-party sticky/fixed navigation capability. Any assessment must therefore start by determining whether the package is redundant on the target Nova version before deciding whether it is viable.

Technical risk. Three risks dominate. First, version drift: an unmaintained CSS-override package against a commercially versioned, frequently updated UI is a near-guaranteed breakage point, and breakage will present as visual regression rather than a hard error — the worst failure mode for detection. Second, licensing ambiguity: the license is declared as NOASSERTION, meaning GitHub could not classify it. Redistribution or inclusion in a client deliverable without a clear license is a legal-review item, not a formality. Third, upgrade friction: pinned positioning often interacts badly with Nova's own sticky elements, dropdowns, and modals (z-index stacking, scroll container changes), so the package can degrade usability in ways that only surface in specific screens. The low opportunity score and the 33-star footprint also signal effectively no community backstop — there is no crowd to shake out regressions on your Nova version.

Key questions.

• Which Nova major version is in scope, and does that version already provide fixed/sticky sidebar behaviour natively?
• What is the actual license, and can it be vendored into our repository or a client deliverable?
• Is the behaviour required on all Nova screens (resources, dashboards, settings, custom tools) or only the index/detail views?
• Will we accept a CSS-override dependency, or is the correct call to implement the equivalent styles in our own Nova custom theme/asset bundle?
• Who owns the fix when a Nova upgrade breaks positioning, and what is our detection path (visual regression tests, manual QA checklist)?

Integration Approach

Stack fit. The package assumes Laravel with Nova installed and Nova's asset publishing available. It is frontend-only and has no bearing on PHP version, database, or hosting topology, so it slots into an existing stack without infrastructure change. The practical constraint is that Nova is a paid, licensed product pinned by composer.json to a major version — the package must be evaluated against that exact pin, not against "Nova" generically.

Migration path. For a greenfield Nova 4/5 install, the recommended path is not to adopt this package. Instead, first verify whether Nova's built-in navigation configuration already satisfies the requirement; if not, reproduce the styling in the application's own Nova asset registration (a small Nova::style() call or a custom theme) so the CSS lives inside the codebase we control. Retain cloudcake/nova-fixed-bars only as a reference implementation for the specific declarations needed. For a legacy Nova 2 application already using it, treat it as frozen: keep it, vendor the stylesheet into the repo, and plan to retire it at the next Nova upgrade.

Compatibility. Expect compatibility to be confirmed empirically, not from documentation. The verification set is small but must be explicit: sidebar collapsed vs expanded, header with and without breadcrumbs/search, long scrolling index tables, modal and dropdown overlays, and the dashboard's grid layout. Because positioning bugs are visual, compatibility sign-off should be a short scripted manual pass against a staging Nova instance at the pinned version, repeated on every Nova minor upgrade.

Sequencing.

1. Confirm Nova version and capture a screenshot baseline of current UI.
2. Check whether native Nova configuration already solves it — if yes, stop.
3. If not, resolve the license question or decide to reimplement rather than depend.
4. Prototype on a branch; run the visual verification set on staging.
5. If adopted, vendor/pin the exact version, document the override in the frontend conventions, and add the visual check to the upgrade runbook.
6. If reimplemented, land the CSS in our own asset bundle and close the dependency.

Operational Impact

Maintenance. This is the dominant cost and it is asymmetric: the package itself will not receive updates, so all maintenance is our maintenance. The realistic burden is a small amount of recurring work tied to Nova's release cadence — inspecting the shell markup after each Nova upgrade and patching selectors. That is low in hours but high in unpredictability, and it lands on whoever owns the admin UI, which is often a thin or shared on-call surface.

Support. No vendor, no maintainer activity since early 2020, and a community too small to rely on for issue triage. Internal support means one or two engineers who understand the override. The NOASSERTION license also means support cannot be escalated commercially and redistribution needs legal sign-off. Budget for this as "self-supported with an undocumented third-party fragment," not as a normal dependency.

Scaling. Functionally irrelevant to scale — it is static CSS with no runtime cost, no queries, and no render-path work beyond the browser. The scaling concern is organisational: the number of Nova screens, custom tools, and bespoke field components in the application increases the surface area where a pinned sidebar or header can misbehave with overlays and scroll containers, so the regression checklist grows with the admin's complexity rather than with user count.

Failure modes. The characteristic failure is silent visual degradation after a Nova upgrade: overlays rendering beneath a fixed header, content clipped behind a pinned sidebar, or double scrollbars. Less common but more disruptive is a broken asset publish causing an unstyled or partially styled admin — recoverable but confusing during an incident. There is no data-loss or security failure mode, which keeps severity low, but the absence of hard errors means the failure will typically be discovered by an administrator rather than by CI.

Ramp-up. Effectively zero for installation and near-zero for comprehension — a new engineer can read the whole package in minutes. The non-obvious ramp-up is contextual: knowing why the override exists, which Nova version it was validated against, and what the fallback is if it breaks. That knowledge must be written down at adoption time, because it will not be reconstructible from the repository a year later.

Recommendation. Treat this as a stopgap, not a dependency. For Nova 2 estates already using it, vendor and pin it with a documented retirement trigger at the next Nova upgrade. For Nova 3+, prefer native Nova navigation settings where they exist, and otherwise reimplement the ~dozen CSS declarations in our own Nova asset registration — the same result, no license ambiguity, no orphaned dependency, and a maintenance path we control.