Feature Flags Livewire Laravel Package

Getting Started

The package is a UI adapter, not a flag engine. It renders Livewire components that flip flags managed by the underlying liberusoftware feature-flags module. Install both:

composer require liberusoftware/module-feature-flags
composer require liberusoftware/feature-flags-livewire
php artisan vendor:publish --tag=feature-flags-livewire
php artisan migrate

Look here first, in this order:

1. composer.json — pin down the Livewire constraint. Livewire 2 vs 3 changes component namespaces, property binding, and wire: attributes; you need to know which world you're in before writing anything.
2. src/Providers/*ServiceProvider.php — confirms whether components auto-register, whether a route or dashboard page is published, and which config keys exist.
3. src/Http/Livewire/ — the actual components. Read the mount() signatures; that's your real API surface.
4. resources/views/livewire/ — the Blade markup you'll be extending or overriding.
5. config/feature-flags.php (or the module's config) — the store driver and cache TTL.

First use case: drop the management panel into an existing admin area rather than building a new screen.

{{-- resources/views/admin/settings.blade.php --}}
<livewire:feature-flags.panel />

If no panel component exists, the next-most-likely primitive is a per-flag toggle:

<livewire:feature-flags.toggle :flag="$flag" />

Verify the component alias by running php artisan livewire:list (Livewire 3) — do not guess the namespace. If the package predates auto-discovery, register manually in a service provider:

Livewire::component('feature-flags.panel', \Liberu\FeatureFlags\Livewire\Panel::class);

Implementation Patterns

Toggle in an admin dashboard. The dominant pattern. Keep the package's panel as a full-page or embedded component inside your existing layouts.app so it inherits auth, navigation, and styling. Override the layout via the published view or the component's layout property rather than rewriting the component.

Gate the UI, not just the flag. The adapter shows toggles; it does not decide who may flip them. Wrap it:

Route::middleware(['auth', 'can:manage-feature-flags'])
    ->get('/admin/flags', FeatureFlagPanel::class);

Read flags outside Livewire. The Livewire components are for writing state. Read flags through the core module so your app doesn't depend on a presentation package at runtime:

if (Feature::active('new-checkout')) {
    return view('checkout.v2');
}

This is the key architectural split: if you use the Livewire namespace in your checkout controller, you've coupled business logic to your admin UI. Don't.

Embed a single toggle in a form. Useful for per-tenant or per-environment flag pages:

<form wire:submit="save">
    @foreach ($flags as $flag)
        <livewire:feature-flags.toggle :$flag :key="$flag->id" />
    @endforeach
    <button type="submit">Save</button>
</form>

Each toggle needs a unique :key when rendered in a loop, or Livewire will reuse DOM nodes and the wrong switch will appear to change.

Optimistic UI with a server-side re-read. Because flag writes usually invalidate a cache, have the component re-resolve the flag after saving rather than trusting the client value:

public function toggle(): void
{
    $this->flag->toggle();
    $this->active = Feature::active($this->flag->name); // authoritative
    $this->dispatch('feature-flag-updated', name: $this->flag->name);
}

Broadcasting changes to other open tabs. If two admins are on the panel, dispatch an event and listen with #[On('feature-flag-updated')] to refresh the list. Cheaper alternative: wire:poll.30s on the panel.

Testing. Livewire components are trivially testable, which is the main reason to prefer this adapter over a hand-rolled form:

Livewire::test(FeatureFlagToggle::class, ['flag' => $flag])
    ->assertSet('active', false)
    ->call('toggle')
    ->assertSet('active', true);

$this->assertTrue(Feature::active($flag->name));

Gotchas and Tips

The license is NOASSERTION. Composer reports no valid SPDX identifier. That is a legal blocker for most production use. Check for a LICENSE file in the repo before adopting; if it's absent, treat the package as all-rights-reserved by default.

Zero stars, zero dependents, future-dated release. A 2026-10-26 release timestamp is almost certainly a packaging artifact or a tag pushed with a wrong system clock. Confirm the package actually installs and resolves with composer why-not liberusoftware/feature-flags-livewire. Version constraints from a mis-tagged release can cascade into dependency conflicts.

Cache staleness is the classic bug. Flip a flag in the Livewire panel, then hit your app in another tab and see the old behaviour. The flag store caches aggressively; the adapter may or may not flush on save. If it doesn't, clear it explicitly in your own listener:

Feature::flushCache(); // check the core module's API for the real method name

Test this deliberately: toggle in the UI, then curl a page behind the flag.

Livewire component state outlives the flag. A public $active property is a snapshot from mount() or hydrate(). Any change made elsewhere — CLI, another admin, a seeder — won't appear until the component re-mounts. Use wire:poll or an explicit refresh action on the panel.

wire:model needs ->live() for instant toggles. In Livewire 3 the deferred default means the switch appears to flip but no request fires until the next action. Add .live to the checkbox, or make it a wire:click="toggle" button instead — the button is more honest about it being a server round-trip.

Auto-discovery can silently fail. If <livewire:feature-flags.panel /> renders nothing and the console shows no error, the alias is wrong. Check the provider's boot() for Livewire::component() calls, and confirm the package's extra.laravel.providers entry survived composer dump-autoload.

Don't edit published views in place. Publish to resources/views/vendor/feature-flags-livewire/ and keep a diff of what you changed. With no upstream activity, you will not get merge conflicts warning you about upstream changes — you'll just drift, and a future release (if one comes) will quietly clobber nothing while your customizations become orphaned.

Extension points to check, in order of value: (1) the published Blade views — always overridable; (2) config keys for the panel route and middleware; (3) the flag service binding — if the adapter resolves the flag repository from the container, you can bind() a decorator that logs every toggle with the acting user, which is the audit trail you will want and which the package almost certainly does not ship.

Log who flipped what. Feature flags are a production control surface. Wrap the core store's toggle method or listen to whatever event the module fires, and write an entry with user_id, flag name, old value, new value. Retrofitting this after an incident is not fun.

Debugging tip. When a toggle appears to save but the flag doesn't change, the failure is nearly always one of three things: the component writes to a different store than your app reads from (config cache), the flag name is being normalized (slugs vs snake_case — check both sides), or a validation rule is rejecting the value silently. Log::info() inside the component's save method resolves all three in under a minute.