Jetstream Bridge Filament Laravel Package

Getting Started

Before anything else: verify the package is real and installable. With zero stars, zero dependents, and a release date in the future (2026-10-26), treat this as unproven code. Spend five minutes on verification before you spend an afternoon on integration.

composer show -a liberusoftware/jetstream-bridge-filament

Read the output carefully: the actual versions available, the declared require block (which Laravel, Jetstream, Fortify, and Filament majors it pins), and the license. The NOASSERTION license means Composer could not map the license file to a known SPDX identifier — that is a legal-review item if this ships in a commercial product.

Minimal install

composer require liberusoftware/jetstream-bridge-filament

If package discovery is enabled (the default), the service provider registers itself. Confirm:

php artisan about          # provider should appear under "Service Providers" if it registers one
cat vendor/liberusoftware/jetstream-bridge-filament/composer.json | grep -A5 extra

If there is no extra.laravel.providers block, register the provider manually in bootstrap/providers.php (Laravel 11+) or config/app.php.

Where to look first — the source is the documentation. This package almost certainly ships no meaningful README. Do this in order:

ls vendor/liberusoftware/jetstream-bridge-filament
cat vendor/liberusoftware/jetstream-bridge-filament/README.md
ls -R vendor/liberusoftware/jetstream-bridge-filament/src
ls vendor/liberusoftware/jetstream-bridge-filament/config
ls vendor/liberusoftware/jetstream-bridge-filament/resources/views

Then find the two things that actually matter:

grep -rn "implements Plugin" vendor/liberusoftware/jetstream-bridge-filament/src
grep -rn "function register\|function boot\|mergeConfigFrom\|loadViewsFrom\|publishes" vendor/liberusoftware/jetstream-bridge-filament/src

That gives you the plugin class, the config key, the view namespace, and the publish tags. Everything else in this assessment assumes you have those four facts in hand.

First use case: register the plugin on a Filament panel that already has Jetstream/Fortify auth behind it, and confirm that Jetstream's profile concepts (name, email, password, and — if enabled — two-factor and API tokens) render inside the panel.

// app/Providers/Filament/AdminPanelProvider.php
public function panel(Panel $panel): Panel
{
    return $panel
        ->id('admin')
        ->path('admin')
        ->login()
        ->plugin(YourDiscoveredPluginClass::make());
}

If the panel loads and the auth pages render, the bridge is wired. If you get a Target class does not exist or a Filament version-constraint error, stop and reconcile versions before going further.

Implementation Patterns

Publish selectively, not wholesale. Publish config first, views only when you intend to override them.

php artisan vendor:publish --provider="Liberusoftware\JetstreamBridgeFilament\JetstreamBridgeFilamentServiceProvider"

Check --tag options if the provider defines them. Publishing views up front is the most common cause of "the package broke after composer update" — published Blade files are frozen in time and will not receive upstream fixes.

Align the three moving parts before writing code. This package sits between Jetstream, Fortify, and Filament, and all three have their own feature flags. The bridge can only present what the lower layers actually enable:

// config/jetstream.php
'features' => [
    Features::profilePhotos(),
    Features::api(),
    Features::teams(['invitations' => true]),
    Features::accountDeletion(),
],

// config/fortify.php
'features' => [
    Features::updateProfileInformation(),
    Features::updatePasswords(),
    Features::twoFactorAuthentication(['confirm' => true]),
],

If a page renders but every action 403s or throws, the mismatch is almost always here, not in the panel provider.

Multi-panel / multi-guard. If you run an admin panel and a user panel, register the plugin per-panel and confirm which guard the bridge resolves. The recurring failure mode is the bridge inferring the guard from Filament's default rather than the panel's authGuard(), which silently shows the wrong user's profile. Test by authenticating two different users on two panels and checking the rendered email address.

Treat the bridge as presentation only. Jetstream's App\Actions\Jetstream\* classes and Fortify's actions remain the source of truth for updates. If you need custom behaviour (e.g. auditing profile changes), hook the action classes or model events rather than subclassing the bridge's Filament pages — the package is a thin adapter, and its internals are the least stable surface it exposes.

Integration tip: after adding the plugin, clear Filament's component cache. Filament caches discovered pages/resources/components, and a stale cache produces confusing "page not found" behaviour that looks like a routing problem.

php artisan filament:clear-cached-components
php artisan optimize:clear
php artisan route:list | grep -i filament

Verify what the bridge actually registered rather than assuming:

php artisan route:list --path=admin
php artisan about --only=environment

Gotchas and Tips

The release date is 2026-10-26. That is in the future relative to normal package lifecycles, which strongly suggests a placeholder, a mis-tagged release, or a version published ahead of its actual content. Do not build on a floating constraint:

"liberusoftware/jetstream-bridge-filament": "0.1.0"

Pin the exact version. If the tag is wrong or the package is a stub, you want the failure at composer install, not three weeks into a sprint.

Zero stars and zero dependents is a real risk signal, not a formality. There is no community to answer questions, no Stack Overflow corpus, and no third party who has already hit your bug. Budget for reading the entire src/ directory — it is likely only a few hundred lines. If it is larger and undocumented, that is a warning: complexity without an audience tends to mean untested branches.

License NOASSERTION. Composer found a license file but could not match it to SPDX. Open vendor/liberusoftware/jetstream-bridge-filament/LICENSE (or LICENSE.md) and read it. If it is absent, the default is "all rights reserved" regardless of the repository being public.

Filament major-version drift is the #1 breakage source. Filament 3 → 4 changed page APIs, form/table namespaces, and action classes substantially. If the package's composer.json allows filament/filament: ^3.0 and your app is on 4, Composer may resolve successfully and then explode at runtime on a missing class. Check the constraint and, if it is loose, add a conflict or an explicit pin in your root composer.json.

Publishing views creates an upgrade trap. Once resources/views/vendor/jetstream-bridge-filament/ exists, every upstream fix is shadowed. If you must override, override the smallest possible partial and leave a note (and a ticket) to re-diff after each update.

Auth/2FA quirks. Two-factor is where bridge packages most often fail: the bridge may expect Fortify's two_factor_secret / two_factor_recovery_codes columns and the encrypt casts to be present and correctly typed. If 2FA screens render but confirmation loops or throws a decryption error, check that User uses Fortify's TwoFactorAuthenticatable trait and that the columns were migrated — enabling the Jetstream feature does not retroactively migrate existing users' data.

Teams context is ambiguous by default. If the panel is team-scoped, verify whether the bridge resolves the "current team" from Jetstream's session-backed currentTeam relation or from a route parameter. Mismatches produce pages that show the wrong team's members with no error at all — a silent, security-relevant bug. Write one feature test that asserts a user sees only their own team's data through the bridge's resources.

Debugging order when something is blank or 500s:

1. php artisan optimize:clear and filament:clear-cached-components.
2. Check storage/logs/laravel.log — Blade errors from an unpublished/missing view namespace usually say so plainly.
3. grep -rn "view(" vendor/liberusoftware/jetstream-bridge-filament/src to see expected view names, then confirm they exist under resources/views.
4. Confirm the panel's authGuard() matches the guard Jetstream/Fortify use.

Extension points, in order of safety: config file → Filament page/resource overrides via panel ->pages([...]) → view overrides → subclassing the bridge's classes. The last option is the one that will break on the next release; if you find yourself there, consider whether you need the package at all versus a small in-house Filament page that calls Jetstream's action classes directly.

Exit criterion. If after a day of reading source you cannot enumerate what the package provides beyond what 30 lines of Filament page code would give you, drop it. The value proposition of a bridge adapter is that it absorbs version churn across Jetstream and Filament — a package with zero dependents has not demonstrated it can do that, and you would be the one maintaining it.