- What is stephenjude/filament-feature-flags used for?
- It is a Filament plugin that provides an admin UI over Laravel Pennant feature flags. You can create and toggle flags, define scopes and conditions, and roll out features per user, team, or custom segment without code changes. It only adds value inside a Filament panel and is a convenience surface rather than infrastructure.
- How do I install filament-feature-flags in a Laravel app?
- Require Laravel Pennant, publish and run Pennant's features table migration, and select the database store. Then require this package, publish its migrations and config, register the plugin on the relevant Filament panel or panels, and define the flag and segment model. A Laravel engineer familiar with Filament should get a first working slice running in one to two days.
- Which Laravel and Filament versions are supported?
- The provided assessment does not specify exact supported major versions, so verify the composer constraints on Packagist before adoption. It expects Laravel 10+ on the Pennant-supported path and an existing Filament panel. Filament major upgrades are the most likely breakage vector because the package sits between independently versioned Filament and Pennant dependencies.
- Does filament-feature-flags work without Filament?
- No. It is a Filament panel plugin, so teams using Nova, plain Blade admin screens, or a separate back-office app get nothing from it. If Filament is not already present, use Laravel Pennant directly and build a small custom screen instead of introducing Filament only for feature flags.
- Can it handle multi-tenancy or custom Pennant scope resolvers?
- This is an unresolved adoption question in the assessment. Confirm whether the package supports Pennant's custom scope resolvers such as resolveScopeUsing and multi-tenancy, or whether it is single-scope and user-only. Test it against your tenant model before relying on it for team or tenant rollouts.
- Does filament-feature-flags support Pennant's rich non-boolean values?
- The assessment flags this as something to verify rather than a confirmed capability. Check whether the UI supports Pennant's rich values or only active and inactive boolean state. If your rollout logic depends on rich values, test that path before adoption.
- Are segments stored as data or code, and can they be evaluated outside Filament?
- The assessment identifies this as a key unknown. Confirm whether segments are stored as data evaluated at runtime or as code-defined closures, and whether they can be evaluated outside the Filament request path. If the package persists segments in its own tables with its own evaluation path, you inherit a schema and semantics you did not choose, which is the main lock-in risk.
- What production concerns should I check before using it?
- Verify who may toggle flags in production through authorization gates, and whether there is an audit trail of who changed what and when. Confirm whether the UI flushes Pennant's cache on toggle or leaves staleness to the operator. Also determine whether it fails open or fails closed if the segment table is missing or evaluation throws.
- How does filament-feature-flags compare to using Laravel Pennant directly?
- Pennant owns flag state and evaluation, Filament owns presentation and access control, and this package glues the two together. It is cheap to replace if abandoned because the actual decisioning remains in first-party Laravel code, but only if you have not built segment logic into its schema. Use Pennant directly when you do not already run Filament.
- Is the package actively maintained and safe to adopt?
- The assessment reports 123 stars, an MIT license, and effectively a single maintainer, with low ecosystem adoption signals. The release date shown as 2026-06-24 is anomalous, so verify actual publication history on Packagist and the commit log before trusting the maintenance signal. The blast radius of abandonment is mostly a UI you could reimplement, unless you depend on its segment schema and semantics.