- How do I install ryangjchandler/filament-feature-flags in a Laravel app?
- Install with composer require ryangjchandler/filament-feature-flags, then register the plugin against your panel inside the PanelProvider. You also need Laravel Pennant installed, published and migrated, because this package is a Filament adapter over Pennant rather than a flag backend of its own. After that, define your features in code and open the panel page. Wiring effort is low; the real work is authorization and scope policy.
- Do I need Laravel Pennant installed for this package to work?
- Yes. This is a thin Filament admin-panel adapter over Laravel Pennant, so Pennant must already be part of your stack and migrated. If your flags are currently resolved through LaunchDarkly, Unleash or a bespoke settings table, adopting this plugin means adopting Pennant first and potentially running two flag systems. Treat Pennant adoption as the go/no-go gate before evaluating the plugin itself.
- Which Filament versions does this plugin support, and will it break on Filament v4?
- The package registers through Filament's plugin API, so check the published constraints in composer.json before committing. That API is not a stable cross-major contract, and a Filament v4 upgrade is a plausible breakage point with no guaranteed upstream fix. Pin exact versions in composer.lock and add a smoke test that boots the panel and loads the flag page, so a version bump fails in CI rather than in an admin's browser.
- Does it support per-user and scoped feature flags, or only global toggles?
- The package is described as toggling features on and off per user or globally, so per-user control is part of the intent. Pennant itself supports scoped features and rich JSON values, but you should verify in the source whether this UI exposes those scopes or only the global toggle. A global switch can misrepresent a flag that is active for a subset of users, which creates false confidence during incident response. Confirm scope and value semantics before relying on the screen for production decisions.
- How is authorization handled? Can any panel user toggle feature flags?
- The plugin composes with Filament's existing auth, navigation and policy layer, and its feature definition flow includes policy-based access control. Verify whether the page is gated by a policy by default or simply visible to anyone with panel access. Deciding who may flip flags in production is engineering work you must budget for, not something installation solves. Start from a restrictive gate and grant access deliberately.
- Do toggles take effect immediately, or does Pennant's cache cause stale results?
- Pennant caches feature resolutions, so a toggle can appear to do nothing if the relevant cache entry is not purged. Inspect the package source for explicit cache invalidation on toggle and test the full round trip in staging. If invalidation is missing or incomplete, wrap the toggle in your own action that clears the flag cache after saving.
- Is there an audit trail showing who toggled a flag and when?
- An audit trail is not part of the documented feature set, so assume you need to add one if you care about accountability in production. Pennant's events plus a small listener, or a wrapper around the toggle action that records the previous value, are cheap ways to close the gap. This is one of the main piece of engineering cost for a plugin that changes production behaviour.
- Can I conditionally show Filament resources, pages and widgets based on a flag?
- Yes. The package lets you conditionally show Filament resources, pages and widgets based on a defined flag, which is much of its value beyond a raw Pennant toggle list. Define flags in code and reference them in your panel navigation or resource registration. Keep those checks thin so that removing the plugin later does not mean unwinding business logic.
- Is this package actively maintained and safe to use in production?
- Adoption signal is close to nil: zero dependents and no visible stars means no production reference implementations to learn from and little community regression pressure. It is single-maintainer software, so bus factor and upgrade support are the dominant risks rather than runtime behaviour. Because the plugin lives in the admin plane and never on the request-serving path, the risk is supportability rather than outages. Treat it as version-locked infrastructure and be prepared to fork or replace it.
- What are the alternatives, and what happens if I remove the plugin later?
- The cheapest alternative is a small Filament resource over Pennant's features table, which caps how much maintenance pain is worth tolerating. Exit cost is near zero as well: dropping the plugin registration leaves Pennant and its stored features intact, and existing flag checks keep working. That reversibility is the strongest argument for spiking the plugin in a non-production panel rather than building your own UI first.