Jetstream Bridge Laravel Package

Technical Evaluation

Architecture fit. This is a classic ports-and-adapters package: it wraps Liberu's identity capabilities (registration, credential update, password reset, profile mutation, team membership) in classes that satisfy Laravel Fortify's invokable action signatures and Jetstream's action contracts. That is the right shape for the problem. Fortify and Jetstream both resolve most behaviour through configurable action class names (config/fortify.php → actions, config/jetstream.php → actions), so a bridge can substitute implementations without touching framework internals. Architecturally it buys you the ability to run a custom identity domain behind a stock-looking Jetstream install — valuable if Liberu identity is a strategic dependency and you want to keep the standard Laravel auth scaffolding.

Integration feasibility. Moderate-to-good in principle, unproven in practice. The integration surface is small: a handful of adapter classes plus published config. There are no service providers with heavy bootstrapping implied by the description, no middleware, no schema of its own — the underlying migrations remain Jetstream's. The realistic effort for a spike is one to three days for a developer familiar with Fortify action wiring.

Technical risk. High, and dominated by project-health signals rather than code complexity:

• 0 stars, 0 dependents, no downstream validation. There is no evidence of production use anywhere.
• The bridge is almost certainly a thin shim over other Liberu modules, which are themselves likely low-adoption. The transitive risk exceeds the direct risk.
• The stated last release (2026-10-27) is anomalous relative to a normal release cadence. Treat it as unverified: confirm whether it is a real tag, a forward-dated tag, or a metadata artifact before relying on it.
• Fortify and Jetstream action signatures are mostly stable but not contractually frozen. Jetstream team actions in particular have shifted across majors. A bridge package with no community is one framework major away from being silently wrong.
• Expected behaviour gaps are the real hazard: event dispatch (Registered, PasswordReset, TeamMemberAdded), password rehashing, email normalization, 2FA recovery-code handling, and profile-photo storage are all places where a substituted action can appear to work while diverging subtly.

Key questions.

1. Which Fortify and Jetstream major versions are declared in composer.json, and is that constraint a range or an exact pin?
2. Does the bridge depend on other Liberu packages, and are all of them published and maintained on Packagist?
3. Are all substituted actions config-swappable, or does adoption require publishing/overriding vendor classes or Jetstream internals?
4. Which capabilities are covered — just Fortify's core six actions, or also teams, invitations, API tokens, 2FA, and email verification?
5. Is there a test suite, and does it assert behaviour parity (events, hashing, normalization) or merely that classes instantiate?
6. Who maintains it, and what is the stated support/upgrade policy?
7. Is the 2026 release date intentional?

Verdict for planning purposes: treat as evaluate-only. Do not place it on the critical authentication path without a successful spike plus contract tests. The adapters are small enough that writing them in-house behind your own interfaces is a credible fallback if the dependency chain proves shaky.

Integration Approach

Stack fit. Assumes a Laravel application already running Fortify and Jetstream (Livewire or Inertia stack) with Jetstream's published migrations. The bridge is additive: no schema ownership, no route ownership. It fits cleanly only if your identity requirements are already aligned with Liberu's model; if you have bespoke identity needs, the adapter layer will fight you.

Migration path. Do not do a big-bang swap. Fortify's actions array and Jetstream's actions array are the seams — substitute one entry at a time.

1. Sandbox a throwaway Laravel app with Fortify + Jetstream installed at your target versions; require the bridge and confirm composer update resolves cleanly with no conflicts against laravel/fortify and laravel/jetstream constraints.
2. Inventory every action the stock install registers, and map each to a bridge-provided equivalent. Anything unmapped is a gap you must fill yourself.
3. Write contract tests against the stock actions first — registration creates a user, fires Registered, hashes the password, sends verification; password reset fires PasswordReset and rotates the token; profile update honours email-change re-verification. Then run the same tests against the bridged actions and diff.
4. Cut over in a non-production environment in this order: profile/password updates (lowest blast radius) → registration → password reset → Jetstream team actions → user deletion. Keep each step independently revertible via config.
5. Only after a full green run in staging, promote. Keep the stock action classes present in the codebase so rollback is a config revert, not a deploy.

Compatibility. Verify three axes explicitly: Laravel major (and PHP version), Fortify major, Jetstream major. Cross-check Jetstream's peer requirement on Fortify — a bridge pinned to an older Fortify can block a Jetstream upgrade. Also confirm that any Liberu modules pulled in transitively do not ship their own migrations that collide with Jetstream's teams/team_user/team_invitations tables.

Sequencing and exit criteria. Gate promotion on: resolved dependency tree with no abandoned transitive packages, passing parity tests, a documented rollback path, and a decision on whether to vendor the source (pin a commit hash, or fork into your own namespace) so an upstream deletion cannot break your build.

Operational Impact

Maintenance. The dominant cost is not code volume, it is ownership of a dependency nobody else uses. You will be the first to hit every incompatibility. Budget for vendoring or forking at the outset; a 0-dependant package on the auth path is a supply-chain single point of failure. Track upstream Fortify and Jetstream releases and re-run parity tests on every major bump.

Support. Expect GitHub issues only, no SLA, likely a one- or two-person maintainer team. Escalation is effectively "fix it yourself." This should be stated plainly to stakeholders: adopting this is closer to adopting sample code than adopting a product.

Scaling. The adapters themselves are negligible — a few method calls per request. Authentication throughput will be governed entirely by Liberu's identity backend and your session/token store. The scaling question to ask is whether the underlying identity capability introduces remote calls, extra queries, or synchronous side effects into the login and registration paths; those are the things that will show up in p95 latency.

Failure modes to design against.

• Contract drift: framework major upgrade changes an action signature; the bridge still resolves but misbehaves. Mitigation: parity tests in CI, pinned versions, staged upgrades.
• Silent behavioural divergence: missing events, skipped rehashing, altered email normalization, unhandled 2FA recovery codes. Mitigation: parity tests that assert side effects, not just return values.
• Transitive abandonment: a Liberu dependency is unpublished or archived, breaking composer install in a clean environment. Mitigation: commit composer.lock, vendor the source, mirror the repository internally.
• Partial cutover inconsistency: some actions bridged, some stock, producing two sources of truth for user state. Mitigation: explicit mapping table and a cutover checklist; avoid long-lived hybrid states.
• Team-membership race conditions: adapters that reimplement invitation acceptance can lose Fortify's transactional guarantees. Mitigation: concurrency tests on invite/accept and last-owner-leaves paths.

Ramp-up. Low for a mid-level Laravel engineer — the public surface is a small set of classes and two config arrays, and a competent developer can read the whole thing in a day. The real ramp-up is Fortify/Jetstream internals knowledge, which the team needs regardless. Plan roughly one engineer-week for spike plus parity harness, and treat that as the cost of deciding whether the bridge is viable, independent of whether you ultimately adopt it. If the answer is no, the harness you built is directly reusable for an in-house adapter layer.