Jetstream Inertia Generator Laravel Package

Technical Evaluation

What it is, in program terms: A development-time scaffolding accelerator, not a runtime dependency. It sits in a bootstrap/dev-dependency slot and never in a production manifest. Framing it this way drives every downstream decision on ownership, upgrade cadence, and capacity planning: it changes how fast a team ships, not what the system runs.

Architecture fit: Narrow and opinionated. It targets Laravel + Jetstream + Inertia (Vue primary, React nominally) + Tailwind, emitting the page tree, layouts, routes, middleware, provider bindings, and npm/Vite wiring Jetstream already expects. Fit is strong for greenfield Jetstream/Inertia apps and repetitive internal admin surfaces. It is nil for API-only Laravel services, Livewire/Blade shops, or front ends where Inertia pages, vite.config.js, and Tailwind config are already customised.

Integration feasibility: Low effort greenfield, medium-to-high retrofitting. The generator writes into files developers typically own — route files, app.js, Vite and Tailwind configuration — so a retrofit becomes a cherry-pick exercise, not an install. The v3.4.0 dependency bump (Inertia, Laravel Vite, Laravel) is the only compatibility signal in the record; it likely aligns with current majors while silently narrowing support for older ones.

Technical risk:

• Version skew. No published support matrix for PHP/Laravel/Jetstream/Inertia/Vite/Node; compatibility is discovered by experiment, converting a cheap tool into an unbudgeted investigation.
• Ownership transfer. Generated files become team-owned source the moment they are committed. Regeneration after an upgrade risks overwriting local customisation — a recurring tax, not a one-time hit.
• Continuity. Single community maintainer, MIT licence, zero dependents, score 0.3, no commercial support path. Abandonment is realistic; blast radius is bounded only because the output is plain Laravel/Vue the team already owns.
• Signal quality. Zero dependents means minimal external battle-testing. Plan as if we are the first serious adopter; the pilot must generate the evidence we lack.

Key questions to resolve before a go/no-go:

• What is the supported version matrix for v3.4.0, and which versions did the dependency bump drop?
• Is there CI or a test suite we can inspect, or is the branch the only evidence?
• Are generator commands idempotent — do they skip, prompt, or overwrite existing files?
• Does it honour our Jetstream feature flags (teams, API tokens, SSR) and both Vue and React paths?
• Maintainer responsiveness over the last 90 days on issues and PRs?
• Command signature stability: how many times has make:jetstream-inertia changed across minors, and is that treated as semver-major?

Integration Approach

Stack fit: Scope adoption to teams already committed to Laravel + Jetstream + Inertia + Vue + Tailwind. Install as a Composer --dev dependency and classify it in the internal tooling catalogue as a project-bootstrap and module-scaffolding tool — explicitly not a framework choice. Note the package-name mismatch: Composer lists savannabits/jetstream-inertia-generator while the repository is coolsam726/.... Record both in procurement, allow-lists, and the internal registry to prevent duplicate adoption or confusion.

Migration path: No big-bang retrofit. Stand up a disposable Jetstream/Inertia spike app (or a feature branch), pin v3.4.0, generate one representative resource, and diff the output against house conventions. Small diff → adopt for new modules only. Large diff → port selectively: take the Pages/ tree and application bootstrap, keep our own Vite, Tailwind, and route files. For a team currently on Jetstream's Livewire stack, this is a stack-migration experiment and must be estimated as one; the package only removes the front-end page-writing portion of that work.

Compatibility: Validate the exact matrix before any commitment — Composer constraints, npm peer dependencies, a clean npm install, a production frontend build, and a separate SSR build if SSR is in scope. Align generator feature flags with the Jetstream install flags; mismatches produce orphaned Teams or API-token pages and missing guards, the most common way a generated app ends up half-wired. The classic false alarm is a Tailwind content glob that misses resources/js/** — check it before declaring the package broken.

Sequencing and decision gates:

1. Confirm supported versions from constraints plus a sample install; publish the matrix internally.
2. Install as a dev dependency on a branch; publish and review config and stubs before generating anything.
3. Generate one module end to end; commit immediately to create a reviewable diff and a rollback point.
4. Run build, tests, and route/auth smoke checks; log every manual fix required and the hours it cost.
5. Go/no-go gate: adopt for new modules, adopt with customised stubs, or reject — decided against measured hours saved, not the demo.
6. If adopting, publish house-styled stubs so generated output matches conventions by default.
7. Lock the version, document the rationale, and publish the policy: generate, then customise; never regenerate over customised files.
8. Re-evaluate only after a second team succeeds with it independently.

Operational Impact

Maintenance: The cost is stewardship, not footprint — maintenance of committed generated code plus periodic upgrade validation. Upgrades are a regenerate-and-diff exercise, so budget a small recurring allowance and expect frontend toolchain churn (Vite, Inertia) to be the likeliest breakage. Pin in the lockfile with a written reason so a routine dependency sweep does not silently move the generator.

Support: Community OSS, no SLA, no escalation path. The internal owner must be named before adoption, not after — whoever is fluent in Laravel, Jetstream, Inertia, and Vite. Publish a short runbook: invocation, generated file mapping, customisation rules, upgrade diff procedure, rollback branch. Given zero dependents, assume we debug novel issues ourselves and price that into the pilot's measured hours saved.

Scaling: It scales horizontally across teams producing similar CRUD surfaces only if conventions live in customised stubs or a starter template. It has no bearing on runtime scaling. Risk grows with the number of apps on divergent Laravel/Inertia versions and with the volume of hand-edited generated files; both are program-level concerns to track, not package concerns.

Failure modes and cheap mitigations: Version mismatch across Laravel/Inertia/Vite/Node; npm or Composer peer conflicts; generated files clobbering custom code; stale scaffolding after a framework upgrade; partially wired apps from mismatched Jetstream/generator flags; maintainer abandonment. Countermeasures are all cheap and should be mandatory: pinned version, spike-app canary, immediate commit for diff review, customised stubs instead of post-editing, documented rollback branch.

Ramp-up: Low for developers already on Jetstream and Inertia — roughly a half-day walkthrough plus one reference module and a conventions note. Medium for teams new to Inertia or Vite, who will misattribute toolchain misconfiguration to package bugs. A greenfield pilot is days. A retrofit into a customised app is a genuine evaluation effort and must not be scheduled as a quick win.

TPM judgement: This is a low-cost tactical accelerator with a bounded blast radius. Fund a one-week, single-module pilot measured against hand-built pages, and let measured hours saved — not the MIT licence — make the case. Its strategic value is optionality: it makes "Inertia" a viable answer in stack-selection conversations and lets us codify house conventions in stubs if multiple teams adopt. Do not make it a platform commitment without a second independent success and a confirmed version matrix; the adoption signals do not support it, and the maintenance-release cadence means we should plan no capabilities that depend on upstream momentum.