Nova Snowball Laravel Package

Getting Started

1. Install via Composer (Nova itself is a private package, so your composer.json must already have the Nova repository configured):

   composer require cloudcake/nova-snowball
   

2. Read vendor/cloudcake/nova-snowball/composer.json first. The require block tells you which Nova major version the theme was built against. Given the Dec 2020 release date, expect laravel/nova: ^2.0|^3.0. This is the single most important file to check before you invest time.

3. Activate the theme. Nova theme packages are activated in one of two ways — check the package's README and its service provider (src/*ServiceProvider.php) to see which it supports:

   • A theme key in config/nova.php:

     'theme' => 'cloudcake/nova-snowball',
     

   • Or an explicit call in App\Providers\NovaServiceProvider::boot(), after parent::boot():

     public function boot(): void
     {
         parent::boot();
         Nova::theme('snowball');
     }
     

4. Publish and clear caches.

   php artisan vendor:publish --tag=nova-snowball   # if the package registers a tag
   php artisan nova:publish
   php artisan config:clear && php artisan view:clear
   

5. First use case to validate: load /nova/login, then the dashboard, then a resource index and a detail view. Themes frequently style the authenticated shell but leave the login page alone — decide early whether that mismatch is acceptable.

Implementation Patterns

Wrap the registration in your own provider. Don't scatter Nova::theme() calls. Create App\Providers\NovaThemeServiceProvider (or a method on NovaServiceProvider) so swapping themes later is a one-line change and the decision is auditable:

protected function theme(): void
{
    if (config('nova.theme_enabled', true)) {
        Nova::theme(config('nova.theme', 'snowball'));
    }
}

Toggle per environment. Drive it from config/nova.php / .env so staging can run stock Nova while production gets the branded look:

'theme' => env('NOVA_THEME', 'cloudcake/nova-snowball'),

This is also your fastest rollback lever if a Nova upgrade breaks the theme — set NOVA_THEME= and redeploy.

Layer your own CSS on top. Treat the package as a base coat, not a finished product. Register a small override stylesheet after the theme via Nova::style() in the same boot() method. Keep overrides in one file with CSS custom properties (--nova-primary) rather than scattering !important across views:

Nova::style('css/nova-overrides.css');

Pair with Nova's branding API. Nova::brand(), Nova::logo(), and Nova::favicon() are cheap wins that make the theme look intentional rather than dropped in.

Style your custom tools and cards to match. Every custom Card, Tool, and Field you write lives outside the theme's CSS scope. Pull the theme's palette (inspect its resources/css for the blue/white values) into your components' Tailwind config so the admin panel doesn't look half-themed.

Fork it for production use. With a 2020 release and 38 stars, treat upstream as a starting point. Fork to a private VCS repo (or a Satis/Private Packagist entry), pin the exact commit in composer.lock, and patch as needed. MIT licensing makes this clean.

Gotchas and Tips

• Nova 4+ compatibility is the big risk. Nova 4 rewrote the frontend (Vite, updated Tailwind, changed theme plumbing). A theme built for Nova 2/3 will usually load but render broken or be silently ignored. Pin Nova to the version the theme supports, or budget time to port the CSS.
• Registration order matters. Nova::theme() called before parent::boot() gets overwritten. Always register after the parent call, and verify by dumping app(\Laravel\Nova\Nova::class) or viewing the rendered <link> tags in the page source.
• The theme may not register itself. Some theme packages ship a service provider, some don't. If nothing changes after install, run php artisan vendor:publish and check config/nova.php — the package may rely entirely on you setting a config key.
• Debugging a blank/unstyled panel: check the browser network tab for 404s on /vendor/... assets, confirm APP_URL matches the host you're browsing, run php artisan nova:publish, and hard-refresh (Nova caches asset manifests aggressively).
• Composer resolution failures usually mean Nova isn't resolvable from the theme's require constraint — e.g. the theme wants laravel/nova: ^3.0 and you're on ^4.0. Use composer why-not cloudcake/nova-snowball to confirm.
• CSS specificity fights. Nova's own stylesheets are Tailwind-heavy; theme overrides targeting bare element selectors will lose to utility classes. Scope selectors to Nova's shell classes and prefer variables over !important.
• No dark mode. A dark-blue/white theme is a fixed palette; it won't respond to prefers-color-scheme. If you need both light and dark, plan for two themes or a media-query override layer.
• Accessibility check. Verify contrast ratios on the dark-blue-on-white combinations for table rows, badges, and disabled states — small custom themes routinely fail WCAG AA on muted text.
• Watch for abandoned-package warnings. composer outdated and composer audit will flag this as stale. Document the fork and your patch history in the repo so the next developer knows why a 2020 package is still in the dependency tree.
• Deploy checklist: composer install --no-dev, php artisan nova:publish, php artisan config:cache, and make sure public/vendor is writable during the publish step on your deploy target.