Jetstream Bridge Api Laravel Package

Technical Evaluation

What this package is. liberusoftware/jetstream-bridge-api positions itself as a presentation adapter — in DDD/hexagonal terms, the inbound adapter that translates HTTP/JSON requests into calls against an application layer, and translates results back into API responses. The "Jetstream Bridge" qualifier indicates its scope is authentication and identity: exposing Laravel Jetstream/Fortify capabilities (login, registration, email verification, password reset, two-factor challenge, profile updates, potentially team membership) as stateless API endpoints rather than Blade/Inertia session flows. It is one module in the broader Liberu modular Laravel suite.

Architecture fit — conditional, and narrow. The hexagonal framing is genuinely attractive: a clean adapter boundary is exactly what we would want if we are exposing an existing Jetstream-authenticated monolith to SPA or mobile clients without duplicating auth logic. Fit degrades sharply outside that scenario. If our target is a greenfield API, we would use Sanctum or Passport directly and gain nothing. If our target is a Jetstream app where the session cookie flow is already correct, the delta we actually need is a thin set of JSON controllers — plausibly a few hundred lines — not a third-party dependency.

Integration feasibility — low confidence. The composite score of ~19.8/100 with 0 stars and 0 dependents means there is essentially no external evidence that this package works outside its author's own applications. A "presentation adapter" is also the most contract-sensitive layer in a codebase: it depends on the application layer's DTOs, commands, and exceptions. Those contracts almost certainly live in sibling liberusoftware/module-* packages, which means the real dependency surface is larger than the single Composer requirement suggests. Until we see the composer.json require graph, feasibility is unverified.

Technical risk. Ranked:

Key questions for the maintainer / our own spike.

1. What is the exact license, and is there a signed CLA or copyright assignment?
2. Full composer.json require/require-dev graph — how many liberusoftware/* packages must be installed?
3. Which Laravel, PHP, Jetstream, and Fortify versions are supported, and is that range CI-enforced?
4. Does it issue Sanctum tokens, Passport tokens, or its own credential scheme? How are token abilities and team scoping modeled?
5. How is the two-factor challenge represented in a stateless request — challenge token, short-lived scoped token, or something else?
6. Is the adapter coupled to Inertia responses, session middleware, or EnsureFrontendRequestsAreStateful?
7. Is there a published OpenAPI/JSON schema for the endpoints, and is it versioned?
8. What is the error contract — Laravel validation exceptions, RFC 7807 problem details, or bespoke envelopes?

Integration Approach

Stack fit. Only a fit if we are standardizing on the Liberu modular suite (Laravel + Jetstream/Fortify + Inertia/Vue) and need a machine-client surface on top of an existing session-based app. On a modern Laravel 11/12 stack, Sanctum already handles SPA-vs-token duality; the marginal value of this package is confined to Fortify feature parity (2FA, verification, password confirmation) over JSON.

Interpret the scores correctly. Opportunity 45 alongside a composite 19.8 is not a contradiction — it says the problem space is underserved, not that this artifact solves it. That is a build signal as much as a buy signal. Our default should be: reproduce the ~5–8 endpoints we need as first-party controllers on top of Fortify's actions, and treat this package as a reference implementation to read, not a dependency to install.

Compatibility. Gate on: PHP 8.2+, Laravel version window matching ours, Jetstream 4/5, Fortify major aligned with Jetstream, and Sanctum if token issuance is delegated. Any pinned-to-minor constraint that conflicts with our lockfile kills it immediately. Verify composer why-not behavior in a scratch project before anything else.

Migration path (if adopted). Because it is a presentation adapter, it should be additive and reversible: routes registered behind a config flag and a route prefix (/api/v1/auth), no changes to existing web routes, no schema changes expected. That gives a genuine kill switch. If a migration is ever needed, the exit is "replace with in-house controllers" — cheap only if we avoid letting the package's DTOs leak into our own application layer. Mandate that our code depends on our interfaces, not theirs.

Sequencing.

1. Week 0 — Legal/diligence. License clarification and dependency graph. Hard stop if unresolved.
2. Week 1 — Read-only spike. Clone, run its tests, enumerate routes with php artisan route:list, diff the endpoint surface against our requirements matrix. No install into a product repo.
3. Week 2 — Contract test. Stand up in a throwaway branch; verify login → token → 2FA challenge → verification → logout against Sanctum and a mobile-shaped client. Measure: does it survive composer update?
4. Week 3 — Build-vs-adopt decision with the spike artifacts as evidence. Bias to build if the endpoint surface we need is under ~10 routes.
5. Post-decision — Vendor or absorb. If adopted, fork-and-pin (never track dev-main) with a documented re-sync cadence. If built, publish internally and record this package as prior art.

Operational Impact

Maintenance. This is the dominant cost. A presentation adapter sits directly on Fortify internals, which are among the most frequently refactored parts of the Laravel auth stack. Expect breakage on every Jetstream/Fortify major. With one maintainer and zero dependents, upstream fixes arrive on the author's schedule, not ours — so adoption implies we are prepared to maintain a fork. Budget that explicitly; "we'll just pin the version" is a deferral, not a plan.

Support. No community, no issue-tracker volume, no security disclosure policy, no Stack Overflow corpus. Internal incident response depends entirely on our own engineers reading the source. Contractually, there is no vendor to escalate to. For anything on the authentication path — the highest-blast-radius surface in the product — that is a material gap.

Scaling. The adapter itself is thin and stateless; throughput is bounded by the underlying token store and database, not by the package. Two real scaling concerns: (a) if tokens are DB-backed Sanctum tokens, token verification cost per request is a query — cache-aware design matters at volume; (b) if 2FA challenge state is stored server-side, that store becomes a hot path and a session-affinity concern. Neither is disqualifying, but both need measuring rather than assuming. Rate limiting on auth endpoints must be verified as present and configurable — this is a credential-stuffing target.

Failure modes.

• Silent auth bypass — a misconfigured route prefix or middleware group exposing endpoints without auth/throttle. Mitigate: automated route-inventory test asserting every auth route carries the expected middleware.
• Version drift — a routine composer update breaks 2FA for a subset of clients; detection depends on integration coverage we must own.
• Contract drift — response shape changes without a version bump, breaking mobile clients already shipped.
• License contamination — discovered post-integration, forcing an emergency rip-out on a security-sensitive path. This is why step 1 is a hard gate.
• Orphaning — author stops publishing; we inherit a fork with no upstream.

Ramp-up. Low for a Laravel-fluent engineer to read (a thin adapter is legible in an afternoon). Moderate to safely operate: they must also understand Fortify's action pipeline, Jetstream's feature flags, and Sanctum's stateful/stateless duality. Realistically 2–3 days of focused onboarding before someone can triage an auth incident in this layer — and that knowledge must not sit with one person.

TPM recommendation. Do not adopt as a production dependency in its current state. The license ambiguity is a standalone blocker and the adoption evidence is nil. Run the one-week read-only spike; in parallel, size the in-house alternative. Given the likely small endpoint surface, first-party controllers over Fortify actions is the lower-risk path and converts an external maintenance liability into an internal asset we control — which, on the authentication path, is where we want the ownership.