Jetstream Laravel Package

Technical Evaluation

Evidence basis for this review. The sources give three partially conflicting signals and very little else: package metadata (0 stars, single v1.0.0 tag dated 2025-11-06, no release body beyond a changelog URL), a description.md that frames the package as a companion that augments Jetstream "without disrupting routes, views, or user flows," and a top-level description that frames it as a self-contained Jetstream successor with teams, custom roles & permissions, and audit logging "out of the box." Those are different products with different adoption costs. Every estimate below is conditional on resolving that contradiction first.

Architecture fit

• This package lives in Laravel's application-substrate tier, not the leaf-dependency tier. Jetstream — and anything claiming to succeed it — owns authentication, session/2FA, API token issuance, team membership, and the Inertia/Livewire UI composition layer. Adoption is therefore an architecture decision with a named owner, not a composer require a feature team makes independently.
• If it is a successor (replaces Jetstream scaffolding), we inherit the full substrate and the maintainer effectively becomes a supplier for our auth surface. If it is a companion (middleware/service-provider overlay), blast radius shrinks substantially and it becomes a normal dependency. The two paths differ by roughly an order of magnitude in migration effort and in long-term lock-in.
• Scope is broader than stock Jetstream: custom roles & permissions and audit logging are not Jetstream features. That is genuine differentiation and a plausible reason to prefer it over vanilla scaffolding — but it also means the package owns an authorization model and a logging pipeline, both of which are compliance-adjacent and both of which we would otherwise have built deliberately.
• Front-end flavor (Livewire vs. Inertia+React vs. Inertia+Vue) is a one-way door at this tier. Choosing the package's stack now constrains UI hiring and future replatforming.

Integration feasibility

• Greenfield Laravel app on an unmodified Jetstream install is the happy path: Composer install, service provider, publishable config, hours not weeks. This is the scenario worth piloting.
• Existing application with hand-modified Jetstream scaffolding is the unhappy path. Published scaffolding lives in app/, resources/views, and routes/ and is routinely customized; a package that manages those same files creates a permanent fork-and-merge obligation rather than an install.
• v1.0.0 is the first tag under a semver scheme with no published notes. It can be read as "API frozen, adopt" or as "0.x line renamed." We cannot tell, and should not guess.

Technical risk

• High — evidence risk. 0 stars and a single release with no notes is thin corroboration for a "production-ready" claim. For a TPM this is a sourcing risk first and a technical risk second.
• High — scaffolding coupling. Highest-probability failure is silent drift between package-owned and project-owned auth/team files. Auth and team-membership regressions are exactly the class of defect that reaches production undetected.
• Medium-High — supplier continuity. Effectively single-maintainer. No commercial backing is documented. If upstream stops, we own a fork of our own login, 2FA, and permission system.
• Medium — security adjacency. Auth guards, token issuance, 2FA, and an RBAC model are in scope by construction. Audit logging additionally means we store a durable record of user actions — a data-retention and PII obligation, not just a feature.
• Low — runtime/infrastructure risk. Pure PHP; no native extensions, no added services.

Key questions (blocking; each maps to a named decision)

1. Successor or companion? Does it replace published Jetstream scaffolding, overlay it, or ship a parallel stack? This single answer determines cost, lock-in, and the entire integration plan.
2. What does the changelog say between the last pre-1.0 tag and v1.0.0 — stabilization, rewrite, or relicense? Is the license compatible with our distribution model?
3. Is there a stated backward-compatibility policy, and a declared Laravel/PHP/Livewire/Inertia support matrix with a tested CI grid?
4. Who maintains it, what is the 90-day commit cadence, and is there a security disclosure policy?
5. Roles & permissions model: is it a gate/policy integration, or its own store? Can it express the tenancy and role granularity our roadmap actually needs?
6. Audit logging: what is written, where, for how long, and can it be purged or exported? Who signs off on the retention policy?
7. Is there a test suite we can read, and does it cover team invitations and role assignment — the historically buggy seams?

Integration Approach

Stack fit

• Assume Laravel 11+, PHP 8.2+, Composer, standard CI. Pin the package's tested range, not its declared floor — Laravel majors move fast and single-tag packages routinely lag a release behind.
• Greenfield, unmodified Jetstream, one front-end flavor: low-friction, and the only context in which the vendor's "minimal setup" claim is plausible.
• Existing customized install: scope this as a project with a budget line, not a dependency addition. If the spike shows the package republishes files we have customized, the default recommendation is defer.

Migration path

• There is no prior adoption here, so there is no upgrade path to plan — the path is greenfield adoption, or a deliberate replacement of an existing Jetstream install.
• Replacement is the expensive branch: it means re-homing customized views, routes, and policy code into the package's structure, and accepting that future upstream releases overwrite our customizations unless the package offers an override mechanism. Get that override story in writing before committing.
• Recommended path: read changelog and tag diff → spike in a throwaway branch of a representative app → diff generated files against our scaffolding → go/no-go on the measured merge cost.

Compatibility

• Build a matrix before any commitment: package version × Laravel × PHP × Livewire/Inertia flavor × our auth requirements (SSO? social? passkeys?). Do not accept "supports Laravel" as a claim.
• Run a transitive dependency check against composer.lock. Livewire and Inertia majors are the usual collision points and a conflict there can block our upgrade path, which is worse than the package simply not working.

Sequencing (TPM-owned gates)

1. Gate 0 — Evidence (1–2 hrs): read changelog, tag diff, license, CI config. Clears questions 1–4. If the maintainer cannot be identified, stop here.
2. Gate 1 — Spike (0.5–1 day, timeboxed): install into a scratch app; measure real setup and developer-experience cost; confirm whether it displaces or overlays scaffolding.
3. Gate 2 — Merge-cost diff (1–2 days): the go/no-go number. Exit criterion should be stated numerically before the diff starts (e.g., "adopt only if fewer than N files conflict").
4. Gate 3 — Architecture + security sign-off: auth surface, RBAC model, audit-log retention, disclosure policy.
5. Gate 4 — Adoption: pin the exact version, add a lockfile-review step, record the fork point, document rollback (revert branch + republish prior scaffolding).

• Schedule this after any in-flight Laravel major upgrade, so the compatibility matrix is tested against the version we will actually run. Do not run it in parallel with an auth-touching feature.

Operational Impact

Maintenance

• Budget an ongoing republish/re-merge line item, not a one-time install cost. Small but permanent.
• Pin to exact 1.0.0 until the maintainer demonstrates BC stability across at least two minor releases. Treat ^1.0 as unacceptable on an auth-tier dependency with no published BC policy.
• Subscribe to the GitHub releases feed via automation — the release bodies are currently a changelog link, so human reading of notes is not a reliable control.

Support

• Community-only by default; no documented commercial backing or SLA. Plan for internal ownership of the auth and RBAC surface if upstream goes quiet, and name that owner before adoption rather than after.
• Record an internal fork point (commit hash at adoption) so a local patch is a one-hour action instead of an archaeology project.
• TPM action: put supplier continuity on the risk register with a review trigger (e.g., "no release in 6 months → reassess").

Scaling

• Infrastructure impact is effectively zero — no services, queues, or new capacity to provision. Scaling exposure is code-shape (N+1 queries in team/role lookups) rather than throughput.
• Audit logging is the real scaling line item. Log volume grows with user activity and never shrinks on its own. That requires a retention policy, a purge/archive job, a storage cost estimate, and — if logs contain user identifiers — a data-protection review. Own this explicitly; it is the one place this package creates an operational obligation.

Failure modes

Ramp-up

• Low for an engineer already fluent in Jetstream — hours to productive. The cost is unlearning: engineers must know which files are package-owned before they touch anything. The one-page file-ownership convention is the cheapest available mitigation for the top failure mode and should ship with the adoption PR.
• TPM ramp is limited to three recurring activities: owning the adoption decision and its gates, watching releases, and reviewing the audit-log retention policy annually. No standing engineering overhead.
• TPM recommendation in one line: approve a bounded, timeboxed spike that answers the successor-vs-companion and scaffolding-ownership questions; withhold standardization and production commitment until the changelog, license, maintainer, and CI matrix are read.