aymanalhattami/filament-slim-scrollbar
Slims down every scrollbar in your Filament app—sidebars, tables, and more—using pure CSS with no JavaScript or extra libraries. Supports both light and dark modes. Just install via Composer and you're done.
Install — this is the whole setup:
composer require aymanalhattami/filament-slim-scrollbar
php artisan optimize:clear
There is no vendor:publish, no config file, no panel registration, no migration. The service provider is auto-discovered and pushes a stylesheet into Filament's asset pipeline, so every panel picks it up on the next request. Reload the browser and the sidebar/table scrollbars are already thinner.
Pin the right major before you commit. This is the only real decision:
| Filament version | Package constraint |
|---|---|
| 3.x / 4.x / 5.x | ^2.x |
| 2.x | ^1.x |
composer show aymanalhattami/filament-slim-scrollbar
If you're on Filament 4 or 5 and Composer resolved ^1.x, stop and re-require — you'll get a stylesheet tuned for Filament 2 markup and nothing will look right.
Where to look first, in order:
vendor/aymanalhattami/filament-slim-scrollbar/src/ — open the service provider. Find the FilamentAsset::register([Css::make(...)]) call (or equivalent render hook). That tells you which panels the CSS attaches to, which matters if you run a panel with a custom ->viteTheme().vendor/.../resources/css/ (or dist/) — grep -rn "scrollbar-width\|::-webkit-scrollbar" and read the whole file. It is genuinely short. Read it before you build anything on top of it, because you'll need to know its selectors to override them later.<nav>, check computed scrollbar-width, and confirm the injected <link>/<style> is actually in <head>. Two minutes here saves an hour of guessing.First use case, validated in one pass. Open a panel that has both an overflowing sidebar nav and a paginated resource table, then confirm:
scrollbar-width/scrollbar-color, not the ::-webkit-scrollbar pseudo-elements)@media (min-width: 1024px), so mobile is intentionally untouched and still shows native scrollbarsFour passes, one screen. If all four hold, you're done — this package's entire job is finished at that point.
Zero-config adoption is the intended pattern. composer require, look at it once, commit the composer.json/composer.lock diff, move on. Do not add a config guard, a feature flag, or an env toggle for this. It's a one-line visual primitive, not an architectural dependency, and wrapping it in conditional logic costs more than the package does.
The per-panel verification pass. Because the asset registers globally, multi-panel apps (admin, app, a customer portal, a panel with a bespoke Vite theme) assume uniformity and are occasionally wrong. Do one manual sweep: each panel × {light, dark} × {desktop, mobile}. Custom-theme panels are the ones that silently miss it, because their compiled theme CSS can override or shadow the package's rules.
Theme ingestion (the recommended endgame for teams that already customize Filament CSS). If you already have:
->viteTheme('resources/css/filament/admin/theme.css')
then the cleanest long-term move is to copy the ~20 lines of scrollbar rules into your own theme file and drop the package dependency. Reasons: one fewer vendor package to audit, the rules live next to the rest of your design tokens, and you can tweak thumb color/width without fighting specificity against a vendor stylesheet. Do this only after you've run with the package for a while and know you like the result — no point front-loading the work.
Scoping to a subset of panels. If you want the slim scrollbar on admin but not on a public-facing panel, don't fight the global asset — add a scoping rule in the panel's own theme or a PanelsRenderHook:
// resources/css/filament/public/theme.css
.fi-panel-public :is(*, ::-webkit-scrollbar) { scrollbar-width: auto; }
In practice most teams just accept the global application; it's a cosmetic improvement, not a branding decision.
Pair it with your own theming pass in one PR. Since it's purely visual and zero-config, bundle it into the same PR as any other Filament theme tweak. Reviewers can validate it with a single screenshot pair (before/after, light/dark). Isolating it into its own PR tends to attract bikeshedding over something trivial.
Locking behavior across Filament upgrades. Filament majors change sidebar/table markup, and the package follows with its own majors. Add it to your upgrade checklist: when you bump Filament, bump this package in the same commit and re-run the four-point validation. Because it's CSS-only and non-functional, a stale version degrades gracefully — you get the old scrollbar look, not a broken page.
CI / visual regression hook (optional, high leverage for design-heavy apps). If you already have Playwright or a screenshot-diff pipeline, add a single assertion on getComputedStyle(sidebar).scrollbarWidth at desktop width and its inverse at mobile width. It catches both accidental removal and accidental over-application (e.g., someone's theme override leaking to mobile).
Mobile is untouched by design. Since 2.1.0 everything is wrapped in @media (min-width: 1024px). If a stakeholder asks "why is the scrollbar still fat on my phone?" — that's intentional, because overlay scrollbars on touch devices shouldn't be forced thin. Don't "fix" it by widening the media query; mobile scrollbars are platform UI.
Firefox and Safari behave differently from Chrome. Chrome/Safari use the ::-webkit-scrollbar pseudo-elements; Firefox uses scrollbar-width/scrollbar-color. The package ships both since 2.1.0, so if you see a fat scrollbar in Firefox you're either on < 2.1.0 or your theme overrode the standard-property block. Safari's overlay scrollbars are OS-controlled and may ignore styling entirely depending on the "Show scroll bars" system setting — that's not a bug, don't chase it.
scrollbar-width is computed on the scroll container, not the child. If a table or sidebar looks unaffected, walk up the DOM from the visible overflow and confirm which element actually owns the scroll. Filament sometimes nests a scroll container two or three levels above where you'd guess, and a table wrapper may set overflow: auto while the actual scroll happens on a parent.
Custom Vite themes beat the package on specificity. If your theme.css sets ::-webkit-scrollbar { width: ... } anywhere, it will win or lose unpredictably depending on load order. Pick one owner: either remove your rule and let the package handle it, or copy the package's rules into your theme and drop the dependency. Don't keep both.
The dark-mode thumb is deliberately low-contrast. Slim scrollbars are less visible by default; on some custom dark palettes (very dark backgrounds with muted thumb colors) users report "I can't tell there's a scrollbar." If you get that feedback, override just the thumb color in your theme rather than reverting to default scrollbars — that's the whole point of the package.
Cache clearing is not optional. Filament caches its asset manifest. After composer require, if nothing changed:
php artisan optimize:clear
php artisan filament:assets # if you use filament:assets in deploy
If it still doesn't appear, check composer show — a wrong major silently resolves to a version with different selectors, which looks exactly like "not installed."
There is no config to publish. If you php artisan vendor:publish looking for a config file, you'll find nothing. All customization is via CSS overrides in your own theme. Accept this early and stop hunting.
The README's version-matrix note links to the wrong repo. It points at filament-page-with-sidebar (the author's other package) for the "version 2.x here" link. Ignore the link; trust the table and composer show.
Extension points are limited to CSS overrides. The package exposes no PHP API, no config, no events, no blade views. If you need something meaningfully different (thicker on hover, custom colors, RTL tweaks, gutter control), the right answer is: copy the rules into your theme, delete the package. Forking a 20-line CSS package to add a hover state is maintenance debt you don't need.
Watch for layout shift when you enable it. Thinner scrollbars free up a couple of pixels of width, which can nudge tightly-fitted table column widths or a sidebar's truncation point. Usually invisible; occasionally it changes where a long nav label ellipsizes. Skim the resource tables you care about after install.
Don't add it to non-Filament parts of the app and assume it applies. The asset registers through Filament's pipeline. If you have a Blade marketing site on the same domain, its scrollbars are untouched — which is usually what you want, but worth knowing before someone files a "inconsistent scrollbars" ticket.
How can I help you explore Laravel packages today?