Jetstream Bridge Livewire Laravel Package

Getting Started

This is a presentation adapter in the Liberu modular stack: it sits between Laravel Jetstream (auth/profile/team scaffolding) and Livewire, letting a module render Jetstream-driven UI through Livewire components instead of Jetstream's default Blade/Inertia stack. Treat it as glue code, not a framework — expect it to be small, and expect to read src/ before trusting it.

Minimal steps

# 1. Confirm the package actually resolves before committing to it
composer show liberusoftware/jetstream-bridge-livewire --all

# 2. Install alongside the versions it was built against
composer require liberusoftware/jetstream-bridge-livewire

# 3. Check what it registered
php artisan about
php artisan route:list --path=user
php artisan vendor:publish --provider="Liberu\JetstreamBridge\Livewire\...ServiceProvider"

Because this is a liberusoftware/module-* package, it may only be published as part of the parent application with a path repository rather than on Packagist. If composer require 404s, look for it in the host app's composer.json repositories block and under modules/ — Liberu projects typically autoload modules from there via nwidart/laravel-modules or a custom modules_statuses.json.

Where to look first, in order

1. composer.json — require constraints for laravel/jetstream, livewire/livewire, laravel/fortify. These tell you which major versions the bridge was written for. Mismatches here are the #1 failure mode.
2. The service provider — what it registers: Livewire component aliases, view namespaces, Blade directives, config merges.
3. config/ — anything publishable (feature toggles for teams, profile photos, API tokens, 2FA mirrors Jetstream's config/jetstream.php flags).
4. resources/views/ — does it replace Jetstream views or wrap them? That determines your override strategy.
5. src/Http/Livewire/ (or src/Livewire/) — the component classes you'll actually instantiate.

First use case

The realistic day-one job is: keep Jetstream's Fortify backend (routes, actions, 2FA, team invitations) but render the profile/team screens with your own Livewire components. Start with the smallest surface — the "update profile information" form — confirm the bridge wires validation, UpdateUserProfileInformation-style actions, and success flash messages correctly, then expand to password update and team management.

{{-- Typical consumption shape; verify the alias against the provider --}}
<livewire:jetstream-bridge::update-profile-information />

Implementation Patterns

1. Adapter-over-Jetstream (the intended pattern)

Leave Fortify/Jetstream actions as the source of truth for business logic and let the bridge supply the presentation. Your Livewire component owns state and validation display; the Jetstream action owns persistence.

use Laravel\Jetstream\Actions\UpdateUserProfileInformation;

class UpdateProfileInformation extends Component
{
    public $state = [];

    public function mount(): void
    {
        $this->state = auth()->user()->withoutRelations()->toArray();
    }

    public function updateProfileInformation(UpdateUserProfileInformation $action): void
    {
        $action->update(auth()->user(), $this->state);
        $this->dispatch('saved');
    }
}

If the bridge already ships this, subclass or compose it rather than duplicating — subclassing is usually cleaner than re-registering the alias.

2. Override-by-alias, not by file surgery

Prefer re-pointing the component alias in your own service provider over editing vendor views. This survives composer update.

// AppServiceProvider::boot()
Livewire::component('jetstream-bridge.update-profile-information', YourComponent::class);

Register after the package provider — ordering matters, and package providers are discovered before app providers by default, so a plain AppServiceProvider registration usually wins.

3. Feature-flag alignment

The bridge almost certainly mirrors Jetstream's config/jetstream.php toggles (profile-photos, api, teams, terms_and_privacy_policy). Any component that conditionally renders must read the same config keys, or you'll get UI for features that have no routes (a 404 on submit). Audit both config files together whenever you toggle a feature.

4. Slot/wrapper composition for layout

Rather than forking layouts, wrap:

<x-jetstream-bridge::layouts.app>
    @livewire('jetstream-bridge.update-password')
</x-jetstream-bridge::layouts.app>

Check the namespace prefix with php artisan view:list if the component tag silently renders nothing.

5. Test at the component boundary

Livewire's test helpers are the fastest way to validate the bridge actually wired things up:

Livewire::actingAs($user)
    ->test('jetstream-bridge.update-profile-information')
    ->set('state.name', 'Ada')
    ->call('updateProfileInformation')
    ->assertHasNoErrors()
    ->assertDispatched('saved');

$this->assertSame('Ada', $user->fresh()->name);

Pin one test per bridging concern (auth guard, team context, 2FA challenge) — these are exactly the seams that break on version bumps.

6. Module integration

Inside a Liberu module, keep your module's Livewire components thin and let the bridge own Jetstream-facing plumbing. Register module components in the module's own provider, not the host app's, so the module stays portable.

Gotchas and Tips

Version triangle. Jetstream 4→5, Livewire 2→3, and Fortify majors have all moved independently. A bridge package written for Livewire 2 ($listeners, mount() + $rules) will explode on Livewire 3 (#[On], dispatch(), form objects). Check composer.json constraints against your composer.lock before installing — and be ready to fork.

License is NOASSERTION. That's not "MIT with a typo" — it means Composer could not identify a recognized license file. Before this goes anywhere near a commercial codebase, open LICENSE/LICENSE.md and get legal sign-off. Also, zero stars / zero dependents / a release date you should sanity-check against the tag list means effectively no upstream support; budget for vendoring or forking.

Silent component failures. If <livewire:...> renders an empty string, it's almost always an unregistered alias, not a logic bug. Debug in this order:

php artisan livewire:make Probe   # confirms Livewire boots at all
php artisan view:list | grep -i bridge
php artisan route:list | grep -i user

In Livewire 3, an unknown component throws; in Livewire 2 it often fails quietly. Blank output = check the alias string character-for-character (namespace separator vs. dot).

Double registration. A "bridge" package often registers aliases that overlap with laravel/jetstream's own Livewire views or with another Liberu bridge module. composer show | grep liberu and look for sibling packages (*-bridge-*) — two bridges registering the same alias means last-writer-wins and confusing, environment-dependent behavior.

Middleware and guards. Jetstream routes live behind auth / password.confirm / verified. If you mount bridge components in your own routes, replicate the middleware explicitly — the component itself won't enforce it:

Route::middleware(['auth:sanctum', config('jetstream.auth_session'), 'verified'])
    ->group(fn () => Route::get('/user/profile', ProfilePage::class));

Tailwind purge paths. Package views not listed in content will render unstyled only in production builds — maddening to debug because npm run dev looks fine. Add:

content: [
  './vendor/liberusoftware/**/resources/views/**/*.blade.php',
]

Extension points to prefer. Service provider bindings, published config, and component-alias overrides are stable-ish. Don't extend the bridge's internal classes directly — with no maintainers, internals are the most likely thing to vanish.

Escape hatch. Keep a documented fallback (Jetstream's stock views, or a hand-rolled Livewire component with the same public API) for every bridged screen. Given the maintenance profile, treat each bridge component as replaceable infrastructure, not a dependency you build on top of.