suraj-kashyap-dev/vesper
Vesper is a Laravel/PHP package from suraj-kashyap-dev that offers a lightweight, developer-friendly way to integrate its functionality into your application. It emphasizes simple setup, clean Laravel integration, and maintainable code for faster feature delivery.
Architecture fit. Vesper is a Laravel package delivered as a Filament panel plugin. The v2.0.0 change moves theming from a publishable config file (~520 lines of presets and design tokens) into package-owned src/Theme classes plus a fluent configuration surface on VesperPlugin. Architecturally this is the right direction: it converts a copy-paste configuration artifact into a versioned, testable API, and it aligns with how Filament expects plugins to be registered ($panel->plugin(...)). For any Laravel application already running Filament panels, the integration boundary is well-defined and small.
Integration feasibility. High. Adoption is a composer require bump plus edits confined to PanelProvider files. The release explicitly preserves config/vesper.php as an optional fallback layer beneath fluent calls, so a 1.x installation continues to render after upgrading without immediate code changes. The migration is mechanical — each previously published config key maps 1:1 to a fluent method (preset, branding, header, sidebar, fonts, colors, tokens, layout).
Technical risk. The dominant risk is silent behavior change rather than hard failure:
config/vesper/tokens.php and config/vesper/presets/*.php are removed and ignored in favor of package data. A team that customized tokens or preset files in place will lose those customizations on upgrade without an error. This is the highest-severity item in the release.TopbarNavigation now read branding/header/sidebar from the active plugin instead of config('vesper.*'). Any locally published or forked Blade view that reads config('vesper.*') directly will silently render defaults or blanks.Preset contract / AbstractPreset is a fresh public extension point; contract stability across 2.x is unproven.VesperPlugin::current() implies multi-panel awareness — behavior with multiple panels and mixed plugin registration is undocumented in the notes.Key questions. Which Filament major versions and PHP versions does 2.0.0 support (constraint diff from 1.x)? Is the config fallback a per-key merge or an all-or-nothing fallback? What is the documented deprecation window for the config path? Do published Blade overrides need republishing, or do they inherit the new plugin-aware behavior automatically? Is there a changelog entry or test coverage for token precedence between tokens() calls and a custom AbstractPreset? What does themeAsset() / themeId() resolve to, and how are asset cache-busting and missing-asset failures handled?
Stack fit. Laravel + Filament admin panels, Tailwind-driven styling, Blade view overrides. Vesper is a presentation-layer concern only — no database, queue, or storage footprint implied by the release notes. That keeps blast radius low and rollback cheap.
Migration path. Two viable routes:
^1.0 until the team has audited its published views and config. Acceptable short-term; 1.x is not described as EOL, but it will diverge.^2.0 in a branch and execute the migration in a single PR:
composer require suraj-kashyap-dev/vesper:^2.0config/vesper.php values into fluent calls in each PanelProviderpresets and tokens keys from the published config (or the whole file if fully migrated)TopbarNavigation against the package versions and replace config('vesper.*') reads with VesperPlugin::current()The recommended end state is the fluent API with the config file removed entirely; treating the fallback as a permanent layer will accumulate two sources of truth.
Compatibility. Config-based theming works as a fallback, so the upgrade can be staged: bump the dependency first (verify nothing visibly breaks), then migrate config to fluent calls panel by panel. The release does not claim 1.x config keys are deprecated with a removal date — treat the fallback as transitional regardless.
Sequencing.
config('vesper, list published Vesper views, list customized presets/tokens.PanelProvider config to fluent calls, panel by panel, smallest-surface panel first.presets / tokens artifacts and any now-redundant config.AbstractPreset / registerPreset extension point if in-house presets existed.Maintenance. Net improvement. Eliminating ~520 lines of published config removes a recurring upgrade tax: no more three-way merges of vendor presets and tokens on every release. Design data now versions with the package, so theme fixes arrive via composer update rather than manual diffs. The cost is a new public API surface the team owns configuration against.
Support. The fluent API is self-documenting and IDE-discoverable via named arguments, which lowers support burden versus editing nested PHP arrays. Counterweight: the Preset contract and VesperPlugin::current() are new primitives that support staff and internal consumers will not know yet. Document the "config is fallback only" rule explicitly, or expect repeated incidents of settings edited in config/vesper.php with no visible effect.
Scaling. Better than 1.x for multi-panel and multi-brand deployments. Configuration is scoped to the plugin instance per panel rather than to a global config file, which is exactly what a multi-tenant or white-label admin needs. registerPreset() gives a supported path for per-brand presets instead of forked config directories. Watch for token sprawl if many teams add ad-hoc tokens() overrides — consider a single shared base preset per brand.
Failure modes.
presets/tokens config ignored after upgrade; theming degrades to defaults with no error. Highest likelihood, moderate impact.config('vesper.*') renders empty branding/help links.AbstractPreset break on a future minor if the contract is not yet frozen.themeAsset() pointing at a moved or unpublished file; verify cache-busting.VesperPlugin::current() returning an unexpected instance when panels are registered conditionally.Ramp-up. Low for the fluent API — a Filament-familiar developer completes the config-to-fluent migration in roughly half a day for a single panel. Budget an additional day for auditing custom views and reconciling any previously customized presets/tokens. Custom preset authoring via AbstractPreset is a moderate step up and should be treated as an advanced task with its own review. Overall: a contained, well-signposted upgrade whose only real hazard is the silent loss of in-place token customizations — mitigate with the inventory step before bumping the dependency.
How can I help you explore Laravel packages today?