Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Nova Fixed Bars Laravel Package

stephenlake/nova-fixed-bars

A Laravel Nova extension that keeps the header and navigation bars fixed while scrolling, improving usability in long resource and dashboard views. Simple to install and configure, it delivers a cleaner, more consistent admin experience with minimal setup.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

What the package actually is. A single Laravel service provider that calls Nova::style(...) to register one small stylesheet (plus a light JS asset) which pins Nova's action bars, sidebar, and navbar to the viewport. There is no server-side logic, no data model, no migrations, no API surface, no queue work. The entire integration surface is one line of asset registration. Everything else in the repository is packaging.

Architecture fit. Narrow but deep: it only functions inside Laravel Nova's compiled Vue SPA. It is inert in plain Blade admin panels, Filament, Voyager, or custom dashboards, and it does nothing if Nova is not installed and credentialed (private nova.laravel.com Composer repo + auth.json). Value is proportional to how many long forms and wide tables the team's Nova resources actually contain — ops/support consoles touching dozens of resources per shift, audit and reconciliation screens, and smaller laptop/tablet viewports are where it pays off. It is not a design-system investment and should not be framed as one.

Integration feasibility. Install cost is effectively zero: composer require, auto-discovery via extra.laravel.providers, no vendor:publish, no configuration. A competent Laravel developer can have it running on a throwaway branch inside ten minutes. The real cost is not build effort — it is validation effort, upgrade ownership, and license clearance. Frame the decision as "their stylesheet vs. our own ~40–60 lines registered via Nova::style()," not "package vs. nothing." At 33 stars, zero dependents, and a single maintainer, "buy" is the wrong frame; the honest options are "lift and own" or "don't do it."

Technical risk.

  • Unmaintained against a moving target. Last release January 2020. Nova 4.x/5.x are the current lines. Nova ships a compiled front end; selectors like .sidebar, .content, and .header are incidental implementation detail, not a public API. Assume every Nova major requires devtools re-inspection and selector retuning — budget roughly half a day per major as a recurring tax, not a one-time install.
  • License is a gate, not a footnote. NOASSERTION in the manifest blocks adoption for anything commercial or client-delivered until legal classifies or waives it in writing, with a named owner for that call.
  • No upstream safety net. No changelog, no release notes, no issue triage, no CVE response, no SLA. An unexplained future tag should never land in an admin UI automatically — read the git tag diff directly.
  • Accessibility regresses quietly. Sticky chrome routinely breaks keyboard focus order, traps scroll, and misbehaves at 200% zoom. No upstream maintainer is watching for this; it becomes our test burden.
  • Silent failure modes. position: fixed is broken by any ancestor with overflow: hidden or transform, and z-index conflicts with modals, dropdowns, toasts, and the mobile drawer are common. These are cheap to fix but easy to miss without a screenshot-diff discipline.

Key questions to settle before commit.

  1. Which Nova major do we standardize on, and who owns admin UI regression review when Nova bumps? That ownership answer belongs in the roadmap regardless of this decision.
  2. Can legal clear or waive NOASSERTION in writing, and who is the named owner?
  3. Is the team able to vendor, patch, or fork this in about a day? At this size, "we can own it" is the real bar.
  4. Do we want fixed sidebar and fixed navbar as independent toggles? The sidebar is usually higher value for ops staff; a fixed navbar eats vertical space and is the likelier annoyance on a 13" laptop.
  5. Which panel(s) benefit — typically the internal ops console, not every Nova panel?

Integration Approach

Stack fit. Requires Laravel + Nova with the private Composer repository configured. The package's laravel/nova constraint in composer.json is the first sanity check and the primary adoption risk signal — a 2020-era constraint against Nova 4.x/5.x should be read as "reference implementation."

Recommended path: lift and own rather than depend. Copy the stylesheet into resources/css/nova-fixed-bars.css, register it in NovaServiceProvider::boot() via Nova::style(), and drop the Composer dependency. This removes the NOASSERTION license question from the dependency graph, eliminates the abandonware risk, and costs roughly a day. Comment the source in the copied file with tag, date, and a note that Nova class names are not a public API and must be re-verified on every upgrade. The cleanest variant is reading theirs and writing our own 40–60 lines once.

If the dependency is retained, pin an exact version ("stephenlake/nova-fixed-bars": "1.1.4"), never a caret range, and never edit published assets without removing the dependency — that is a silent fork.

Sequencing.

  1. Confirm Nova is installed and record the exact version. No Nova, no package; stop here.
  2. Ten-minute validation spike on a throwaway branch. Seed 50+ records, open the resource index, scroll to the bottom. Verify: no 404s for the stylesheet in console; sidebar and top bar stay pinned; content is not hidden underneath fixed chrome; the mobile drawer still opens at 375px.
  3. Decide per toggle. Fixed sidebar and fixed navbar are separate decisions with separate tradeoffs. Ship two independent toggles gated behind config, not one.
  4. Gate behind config so it can be killed in one deploy. NOVA_FIXED_BARS env flag read in config/nova.php, checked before the Nova::style() call. Never ship a visual override that requires a revert to disable.
  5. Register per panel, not globally. Use Nova::whenServing() scoped to the internal ops panel.
  6. Validate with a screenshot-diff matrix. 375 / 768 / 1024 / 1440 px across dashboard, resource index, detail, create/edit, a modal, and a screen with an already-sticky toolbar. Diff against main; PR includes before/after images and the Nova version validated against.
  7. Ship with a documented rollback: flip the config flag.

Compatibility practices.

  • Prefer CSS over any JS measuring shim. Nova is a Vue SPA — route changes swap content without a page reload, so any offset computed on load goes stale on the first navigation. Use calc() and CSS custom properties.
  • Tokenize dimensions once. A --nova-bar-height variable consumed by both the fixed element and the compensating padding-top/margin-left; never hardcode the same pixel value in two places. The most common "looks broken" failure is a fixed sidebar with a content wrapper that no longer knows its width.
  • Scope every rule under a body class we control for contained specificity, and confine !important to specific properties (position, top, height) rather than whole rules.
  • Let Nova own small widths. Explicitly revert to position: static under ~1024px so Nova's own mobile drawer keeps managing navigation. This is where nearly every layout regression surfaces.
  • Inherit Nova's CSS variables for colors and borders so the bar stays consistent under custom themes.
  • Never patch anything under vendor/laravel/nova — it is overwritten on every install.
  • Time the work around Nova upgrades. Do not land this immediately before a Nova major; schedule validation after the bump instead.

Operational Impact

Maintenance. The recurring cost is re-validation, not operation: roughly half a day per Nova major, plus a devtools re-inspection pass to retune selectors, plus asset republishing (php artisan nova:publish) and cache-busting after any CSS edit. Asset caching will otherwise hide changes and generate false "it didn't work" reports. Ownership must sit with whoever owns the Nova application — an unowned front-end overlay decays silently.

Support. No vendor, no SLA, no changelog, no issue triage, no CVE response. Internal support is entirely first-line: whoever owns the Nova app also owns the CSS. That is acceptable for internal tooling and unacceptable for anything with a support obligation attached. Treat any future upstream tag as unreviewed code until the diff is read.

Scaling. Runtime cost is negligible — one stylesheet and a small JS file, no database, queue, or server-side load. It scales with the number of panels and screen classes covered, not with user count. Multi-panel deployments register the asset per panel rather than globally, which keeps blast radius contained to the internal ops console.

Failure modes to instrument in the runbook.

  • Content hidden under fixed chrome / broken offset: the sidebar is out of flow and the content wrapper lost its matching margin-left at one or more breakpoints.
  • z-index collisions: a high value covers modal backdrops or traps dropdowns behind the header. Use the lowest value that pins the bar above content, then re-verify dropdowns, modals, toasts, and the search overlay after every change.
  • "The CSS is right but nothing happens": an ancestor has overflow: hidden or transform, creating a new containing block that breaks position: fixed silently. Diagnostic order is always: (1) is the rule in computed styles at all, (2) is Nova's own rule winning on specificity, (3) is an ancestor creating a containing block.
  • Mobile drawer regressions at small widths, and fixed chrome eating vertical space on 13" laptops — mitigated with an escape-hatch media query at low viewport heights.
  • Print and PDF exports clipped — needs a @media print rule reverting fixed elements to static, otherwise exported resource lists lose headers.
  • Accessibility: keyboard focus order, scroll trapping, and 200% zoom must be tested by tabbing a resource index end to end and zooming before every release. No upstream maintainer is performing this check.

Ramp-up. Installing is trivial for any Laravel developer; owning it correctly is moderate. The skills that matter are CSS specificity management, screenshot-diff discipline, and accessibility verification — not Laravel expertise. Budget the first adoption as a one-day lift-and-own exercise plus the validation matrix, then a standing half-day per Nova major. The discovery work produced during evaluation — whether sticky chrome breaks focus order, zoom, the mobile drawer, and modal stacking — is reusable as a spec if the team later invests in admin UX properly, which is the more durable outcome regardless of whether this specific package is adopted.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console