Dash Stack Theme Juniyasyos Laravel Package

Getting Started

This is a Filament PHP theme package (v3-era Filament assumed) that ships a DashStack-branded admin shell. Given the package has zero stars and zero dependents, treat it as early-stage — verify the actual README and composer.json before committing, since API stability is not yet proven by community adoption.

Minimal install path:

composer require juniyasyos/dash-stack-theme-juniyasyos

Then register the theme on your panel. Filament v3 themes are typically applied via ->viteTheme() (if the package ships a Vite entry point) or ->theme() (if it ships a compiled CSS file):

// app/Providers/Filament/AdminPanelProvider.php
public function panel(Panel $panel): Panel
{
    return $panel
        ->default()
        ->id('admin')
        ->path('admin')
        ->viteTheme('vendor/juniyasyos/dash-stack-theme-juniyasyos/resources/css/theme.css')
        // or ->theme('vendor/juniyasyos/dash-stack-theme-juniyasyos/dist/theme.css')
        ->login();
}

Where to look first, in order:

1. README.md in the repo — the source of truth for the exact ->theme() signature.
2. composer.json — confirms Filament version constraint (v3.x vs v4.x), Laravel minimum, and whether it declares a service provider with extra.laravel.providers.
3. src/ — check for a *ThemeServiceProvider or *PanelServiceProvider that auto-registers.
4. resources/ or dist/ — whether assets are pre-built or require a Vite build.

First use case to prove it works: apply the theme to a throwaway panel, hit /admin/login, and confirm the DashStack layout, colors, and font load. If the login page looks like vanilla Filament, the theme isn't wired — check the Vite build step next.

Implementation Patterns

Panel-level theme application. Most likely the intended pattern, and the safest one against future package changes, is applying the theme explicitly in each PanelProvider. This keeps the dependency visible in your app code rather than hidden inside a vendor auto-registered provider.

->viteTheme('vendor/juniyasyos/dash-stack-theme-juniyasyos/resources/css/theme.css')

Publishing then extending. If the package offers php artisan vendor:publish, publish the assets into resources/css/filament/admin/theme.css and treat the vendor file as a starting template. You then own the file and can layer Tailwind overrides:

@import '../../vendor/juniyasyos/dash-stack-theme-juniyasyos/resources/css/theme.css';

.fi-sidebar { --dashstack-sidebar-width: 16rem; }

This is the workflow you want day-to-day: vendor theme imported as a base, your project's theme as the last word.

Multi-panel setups. Because themes are panel-scoped in Filament, you can apply DashStack only to the admin panel and leave a customer-facing panel on the default theme. Keep a PanelTheme enum or config value so you aren't hunting strings across providers.

->viteTheme(config('themes.admin'))

Tailwind content scanning. If you publish assets, make sure your tailwind.config.js content array includes your app/Filament/**/*.php, resources/views/**/*.blade.php, and — critically — the package's Blade views if you override layouts from it. Forgetting the vendor path is the #1 cause of "my custom classes don't compile."

Dark mode and brand colors. Filament exposes ->colors() and ->darkMode(). Layer these on top of the theme rather than editing the theme CSS:

->colors(['primary' => Color::Indigo])
->darkMode(true)

Deployment workflow. Compiled assets must land in public/. If the package ships a Vite entry, npm install && npm run build before php artisan filament:assets — and make sure your CI runs the same build step, otherwise staging and prod will drift.

Gotchas and Tips

• Zero-stars package. Pin the version in composer.json ("juniyasyos/dash-stack-theme-juniyasyos": "1.0.*" or a commit hash) and treat upgrades as manual review events. With 0 dependents there's no community safety net; you are the QA.
• ->theme() vs ->viteTheme(). This is the most common failure mode. ->theme() expects a path in public/ (compiled CSS). ->viteTheme() expects a path Vite can resolve and requires a running build manifest. Getting this backwards produces a silent no-op or a 404.
• Cache the theme is not enough. After changing theme wiring, run php artisan optimize:clear — Filament caches panel configurations and stale config will keep you debugging ghosts.
• Asset publishing on deploy. php artisan filament:assets copies Filament's own assets. Theme assets may be separate. Check for a --tag you're supposed to pass and add it to your deploy script explicitly.
• Layout overrides are version-fragile. If the package ships Blade overrides under resources/views/vendor/filament-panels/, a Filament minor upgrade can break them. Keep a smoke test that renders the dashboard, or at least hit /admin on every deploy.
• Tailwind purge surprises. Custom components from the theme may use class names built dynamically; if you see missing styles after a production build, check safelist in tailwind.config.js.
• Filament version mismatch. The package was released 2025-08-01 — confirm it targets the Filament major you're on. A v3 theme wired into a v4 panel will register but render broken layouts with confusing console errors.
• Extension points unknown. Because docs aren't guaranteed, prefer wrapping (a custom PanelProvider method or a dedicated app/Filament/Themes/DashStack.php class) over editing vendor files. That way when the package is abandoned — a real risk at zero stars — you can replace the theme without touching the rest of your app.
• Debugging tip. If the theme loads but looks wrong, open DevTools and confirm the theme.css request returns 200 and is non-empty. If it's 200 but styled as vanilla, the file loaded is Filament's default — your panel provider didn't pick up the theme. If it's a 404, you're on the wrong method.