Filament Palette Laravel Package

Product Decisions This Supports

• Feature scoping for theming / white-labeling: A drop-in palette switcher for Filament panels lets us decide whether per-user or per-tenant theme switching is a "buy" (adopt this package) or "build" (custom panel middleware + CSS variables). If theming is a nice-to-have rather than a differentiator, this is a low-cost experiment; if it's core to a branded multi-tenant product, plan for a maintained internal fork or an abstraction layer.
• Roadmap sequencing for admin UX: The v1.1.0 work is infrastructure, not features — configurable cache store, dev-environment fallback, Pest/Testbench suite, PHP 8.2–8.4 CI. That tells us the maintainer is investing in reliability fit for production pilots, so we can schedule adoption earlier (e.g., behind a config flag in an internal admin) instead of waiting for a 2.x signal.
• Build vs buy / dependency posture: Removing composer.lock from VCS and stripping dev files via .gitattributes reduces install footprint and dependency-conflict risk in our app's composer.json. Both are explicit green flags for adding a small third-party package to a shared Laravel codebase.
• Environment-parity decision: The "smart fallback" to the file cache driver when the app uses array/null caches prevents the classic "my theme keeps resetting locally" bug that generates support tickets and erodes trust in a new admin feature. This lowers the QA and onboarding cost of shipping the feature to internal teams.
• Operational/config decision: FILAMENT_PALETTE_CACHE_STORE gives us an explicit lever to keep palette state in Redis in production (multi-node consistency) while avoiding cross-tenant cache key bleed — a decision we would otherwise have had to make through a fork.
• Adoption gate for a pilot: With an actual test suite and CI matrix where previously unknown, we can justify a time-boxed pilot in a non-customer-facing panel and set a re-review checkpoint at the next minor release.

When to Consider This Package

Adopt when:

• We are already on Filament and want user-selectable palettes/themes without writing our own state-persistence layer.
• Theming is a secondary UX concern — a handful of palettes, per-user persistence, admin-panel only.
• We run a modern PHP/Laravel baseline (PHP 8.2+, per the CI matrix) and can point palette state at a durable cache store (Redis, database, file) in production.
• We want a short evaluation cycle: the package is small, dev files are stripped on install, and configuration is env-driven, so a spike is cheap.

Look elsewhere or reconsider when:

• We need per-tenant theming with strict isolation guarantees. Cache-backed state and a single global config key are not a tenancy model; we would need to verify key namespacing ourselves or build our own.
• Theming is a brand-critical, customer-facing surface. A 1.x community package with a single maintainer is a poor place to put a visual differentiator; budget for a fork or in-house implementation.
• We cannot accept cache as the source of truth — if the palette must survive cache flushes deterministically or be auditable, a database column is the right primitive.
• Our app relies on non-file ephemeral caches outside local dev, or we need store selection per panel/tenant rather than globally.
• We need documented support, SLAs, or guaranteed upgrade paths — no evidence of that here.
• Filament itself changes its theming/asset APIs in a major version; treat this package's compatibility lag as a standing risk and re-evaluate at each Filament major.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost add-on to our existing admin framework that gives users a choice of visual themes. The newest release is about de-risking, not new features: the maintainer added automated tests, continuous integration across current PHP versions, configurable storage for theme preferences, and safeguards so themes don't silently reset on developers' machines. It also slimmed what gets installed into our app. Recommendation: approve a time-boxed internal pilot in a non-customer-facing panel, not a broad rollout — the package is early-stage and single-maintainer, so we should keep the integration behind a thin internal abstraction that we could replace with our own code in days if needed.

For engineering: v1.1.0 makes adoption materially safer than v1.0.x. FILAMENT_PALETTE_CACHE_STORE lets us pin palette state to Redis in production instead of inheriting whatever the app default is; the automatic file fallback fixes local-dev theme persistence when CACHE_STORE=array; composer.lock removal and .gitattributes mean no dependency pinning conflicts and no test/CI files in our vendor tree. Pest + Testbench suites and a PHP 8.2/8.3/8.4 GitHub Actions matrix are a real reliability signal. Concrete asks before we merge: (1) confirm production cache store and key namespacing, including tenant bleed risk; (2) wrap the package behind our own ThemeService/config boundary so a swap is a one-file change; (3) pin the version constraint and add it to our dependency-review list; (4) treat Filament major upgrades as a re-review trigger.