Filament General Settings Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-configurable settings. This package removes the need to hand-roll a settings screen in Filament: it gives you a persisted key‑value settings store plus a ready-made admin page, so "let ops edit app settings without a deploy" becomes a configuration task instead of a sprint of custom CRUD work.
• Roadmap: self-serve configuration for non-technical users. The v1.0.27 docs addition — the RichEditor custom field type with toolbarButtons config — is the meaningful product signal. It means settings values can be rich text with a controlled editing toolbar (e.g., announcement banners, policy/legal copy, onboarding messages) authored by admins, with the toolbar constrained to the formatting you want to allow (no raw HTML injection, reduced support burden). That converts a class of "please change this copy" requests from engineering tickets into admin self-service.
• Feature scoping for settings-driven surfaces. Because field types are pluggable, you can model settings forms (toggles, selects, rich text, custom fields) and reuse them across features: feature flags, notification templates, branding, contact details, terms acceptance text. Decide what to expose to admins and how it's edited without building a form framework.
• Upgrade/risk decision for the current release. v1.0.27 is a patch release with no breaking changes: documentation plus a dev-only dependency bump (esbuild to ^0.25.0, CORS leak in the dev server, CVSS 5.3, no production runtime impact). It is a safe, low-risk upgrade; schedule it in a normal maintenance window rather than treating it as a migration.
• Maintenance-health signal for "buy" bets. A release that is documentation and dependency hygiene (rather than churn) is a positive indicator that the maintainer is tending the package; useful evidence when justifying depending on it.

When to Consider This Package

Adopt it when:

• Your stack is Laravel + Filament and you need editable application settings (globals, key–value config) with an admin UI rather than env/config files.
• You want admin-editable content and settings — including rich-text fields with a deliberately limited toolbar — without building a settings module.
• You value fast time-to-value over deep customization: a small team or MVP that needs settings management this sprint, with pluggable field types to cover common inputs.
• You want a low-risk dependency: small surface area, no breaking-change history in this patch, and simple semantics (read/write settings by key).

Look elsewhere or build your own when:

• You need complex, relational, or highly validated settings schemas (nested structures, per-entity overrides) — a key–value store plus form fields may become a poor fit and a custom domain model is cleaner.
• You require multi-tenant settings at scale with strict isolation, audit trails, approvals, or versioned config — plan for additional engineering or a dedicated configuration service.
• You are not on Filament (or on a different admin stack), or you want settings managed purely as code (config-as-code, GitOps) with no database-backed admin editing.
• You need guaranteed API stability or vendor support — this is community-maintained; treat it as a dependency you can fork/patch if needed.

How to Pitch It (Stakeholders)

For executives: We can ship "admins can edit app settings themselves" without a build project. This package provides the settings storage and admin screen inside our existing Laravel/Filament admin panel, so non-technical staff can change things like banners, policies, and contact details — including formatted rich text with a restricted toolbar — instead of filing engineering tickets. The latest version (v1.0.27) is a small maintenance release: documentation improvements and a development-only security patch for a build tool. There are no breaking changes, no production security exposure, and no migration work — upgrading is a routine maintenance task. Net effect: lower cost, faster iteration, and fewer low-value tickets on the engineering team.

For engineering: v1.0.27 documents the RichEditor custom field type with toolbarButtons configuration and bumps esbuild to ^0.25.0 (GHSA‑67mh‑4wv8‑2f99, dev-server CORS leak, CVSS 5.3 — dev dependency only, nothing ships to production). Upgrade path is a standard dependency bump with no API changes. The package's value is a pluggable settings form over a key–value store: standard field types plus custom ones, so we get an admin settings page without bespoke CRUD. Caveats to note: keep it to straightforward global settings; if we later need per-tenant, audited, or versioned configuration, we should expect to extend or replace it. Recommend adopting, pinning the version, and watching upstream for breaking changes.