Feature Flags Filament Laravel Package

Technical Evaluation

What this package is. liberusoftware/feature-flags-filament is scoped as a presentation adapter — not a feature-flag engine. It almost certainly supplies Filament panel resources/pages/widgets that render and mutate flags owned by a separate core module (a feature-flags domain package) inside the Liberu modular Laravel monorepo. That framing drives the entire assessment: the package's value is UI ergonomics and admin governance, not flag evaluation, storage, or targeting logic.

Architecture fit. The adapter split is sound and idiomatic for Laravel/Filament: domain logic behind an interface, Filament as a thin admin surface, Livewire for interactivity. For a TPM this is a positive architectural signal — it implies the flag engine can be swapped (Pennant, LaunchDarkly, Unleash, custom) without rewriting the panel. The risk is the inverse: if the adapter is tightly coupled to a proprietary core module's models, actions, and naming conventions, the "adapter" is only portable within Liberu's ecosystem. That is the single most important thing to verify by reading the source.

Integration feasibility. Low technical effort, high unknown count. Filament plugins are conventionally one-line registration via a plugin class plus a service provider; if this package follows that pattern, a spike is measured in hours. Feasibility collapses if the package hard-depends on unpublished sibling packages (dev-only path repositories, @dev constraints), which is common in single-vendor module suites.

Technical risk. Material, and concentrated in due diligence rather than engineering:

• Maturity: 0 stars, 0 dependents, no external consumers. No signal of production use, no community backpressure on breaking changes, no third-party bug reports to learn from.
• License: NOASSERTION is a blocker, not a footnote. It means GitHub could not detect a standard license. Until legal review resolves it, this cannot ship in a commercial product. Treat as "all rights reserved by default" until proven otherwise.
• Release metadata anomaly: last release dated 2026-10-26 is future-dated relative to normal consumption. Verify whether this is a mistagged/scheduled release, a private-registry artifact, or a clock error — and confirm an installable tag actually exists on Packagist.
• Version coupling: Filament v3 → v4 (and Livewire 2 → 3) are breaking transitions. A UI adapter is exactly the layer that breaks hardest and gets fixed last.
• Bus factor: single-vendor, single-maintainer, no fork community.

Key questions to answer before any commitment

1. Which Filament major does it target, and is that constraint a caret range or a pin?
2. Does it require the Liberu core feature-flags package, and is that package published, licensed, and maintained?
3. Does flag mutation go through a service/action layer (testable, auditable) or direct Eloquent writes from a Livewire component?
4. Is authorization exposed via Filament policies/Gates — i.e., can we gate flag toggling to specific roles?
5. Does it handle multi-tenancy (per-tenant flags), and how does it invalidate cache on toggle?
6. Is there an audit trail for who flipped what, when? This is the main reason to buy rather than build a panel.
7. What is the actual license text in the repository root?

Integration Approach

Stack fit. Strong on paper: Laravel + Filament + Livewire is a mainstream combination, and an admin panel is the lowest-risk place to introduce an unvetted dependency — it is not on the request path, so a defect degrades operator experience rather than customer traffic. That containment is the core argument for piloting it.

Migration path. Do not adopt as a greenfield flag system. Adopt as a replacement for an existing stopgap admin surface — typically a hand-rolled Blade CRUD screen or direct DB edits — behind a stable internal interface. Sequence:

1. Source audit (0.5–1 day). Read composer.json, the service provider, the Filament plugin/resource classes, and the license file. Confirm dependency closure is all public.
2. Legal clearance. Resolve NOASSERTION before writing integration code. This gates everything.
3. Isolated spike. Fresh Laravel app + Filament at the target major + the package, in a scratch repo. Confirm the panel boots and a flag can be created/toggled. No production code touched.
4. Interface seam. Define an internal FlagAdmin contract in your own codebase; let the package sit behind it. This is the insurance policy that makes the vendor risk tolerable.
5. RBAC + audit. Wire Filament policies and confirm audit logging exists or is addable. Flag toggling is a privileged operation and must be attributable.
6. Pilot in staging, then a single internal/admin-only production panel.

Compatibility. Pin exact versions of Filament, Livewire, and PHP; do not accept floating constraints on a 0-star package. Verify against your Laravel major and PHP minor. Expect to hold Filament upgrades until the adapter catches up — budget for that, or plan to fork.

Sequencing note. Because the adapter depends on a core module, integration order is core-first, adapter-second. If the core package is not independently consumable, stop: you are not integrating a package, you are adopting a monorepo.

Operational Impact

Maintenance. This is the dominant cost. With zero external consumers, you are effectively the only QA function. Assume you will fork within 12 months if the feature proves valuable; the fork cost is small (it is a thin UI layer) but the decision to fork must be planned, not discovered. Budget a named owner and a quarterly review of upstream activity. If upstream is dormant, treat the code as vendored.

Support. No community, no issue-tracker history, no Stack Overflow corpus. Support is whatever the vendor relationship is — and for an organization without a commercial agreement, that is zero. Internal documentation of the integration becomes mandatory, not optional.

Scaling. Negligible runtime scaling concern: an admin panel serves tens of concurrent operators, not millions of requests. The scaling question is flag evaluation, which lives in the core package, not here — specifically cache invalidation latency when an operator flips a flag. Ensure toggles publish an event and that evaluation caches are short-TTL or event-driven. An admin UI that appears to change behavior but takes minutes to propagate is a trust-destroying failure mode and will be blamed on this package regardless of where the bug lives.

Failure modes.

• Boot failure: Filament/Livewire major mismatch takes down the whole panel, not just this feature. Mitigate by registering the plugin conditionally and testing upgrades in CI.
• Silent no-op toggles: direct model writes bypassing the flag service, producing DB state that the evaluation layer ignores.
• Orphaned flags: deleted features leaving live flag rows; needs a cleanup/lifecycle convention.
• Unaudited privilege: anyone with panel access can flip production behavior with no record.
• Abandonment: upstream stops; you inherit the code with no upgrade path.

Ramp-up. Low for engineers familiar with Filament (hours to productive, days to confident). Effectively zero end-user training — the value proposition is that operators stop editing the database by hand. The real ramp-up cost is organizational: establishing who is allowed to toggle flags, and the audit/review norm around it.

TPM recommendation. Treat as a high-optionality, low-confidence candidate — consistent with the 19.8/100 score and 0-star signal. The architecture is sensible and the integration cost is genuinely small; the license ambiguity, absent community, and vendor-coupling risk mean this should not enter a critical path. Approve a timeboxed spike (1–2 engineer-days) conditional on license resolution, and hold a build-vs-adopt decision until the source audit answers whether the adapter is portable or monorepo-bound. If the answer is "portable and MIT/Apache," it is a cheap win. If it is "requires unpublished sibling packages under an unclear license," the correct decision is to build a small Filament resource in-house and revisit in two quarters.