Laravel Typescriptable Laravel Package

Product Decisions This Supports

• Feature scoping for Inertia-based apps. The package makes the backend→frontend contract (Eloquent models, named routes, Spatie Settings) an artifact generated from source rather than hand-maintained. That supports decisions like "can we ship this admin/settings screen this sprint?" because the type work becomes near-zero instead of a day of hand-written interfaces.
• Build vs. buy (vs. hand-roll). The realistic alternatives are: hand-written TS interfaces (drift, maintenance load), OpenAPI/Scribe + openapi-typescript (heavier, schema-first, decoupled from Eloquent), or Laravel Wayfinder (routes only). This package is the narrow, cheap option when you're staying inside a Laravel/Inertia monolith and want models + routes + settings from one tool.
• Roadmap: frontend/backend contract as a first-class deliverable. If your roadmap includes multiple frontend surfaces (web app, admin panel, tenant dashboard) against one Laravel backend, generated types turn "keep the contract in sync" from a process problem into a CI check.
• Use cases worth flagging: admin panels and internal tools (settings screens map directly to Spatie Settings), Inertia + Vue/React apps with strict TypeScript, and teams that rename DB columns or route params often.
• A metric this moves: frontend runtime errors caused by backend contract changes (renamed attributes, missing props, wrong route parameters). These are cheap to fix but expensive to catch late; generated types move detection from QA/production to CI.
• Decisions it does not inform: pricing, packaging, or anything customer-facing. This is an engineering-leverage call, not a product-differentiation call.

When to Consider This Package

Adopt when most of these hold:

• You run Laravel + Inertia (the optional NPM package is the tell — this is the primary intended path).
• Your frontend is strict TypeScript and the team already feels the pain of hand-written model interfaces.
• You use Spatie Laravel Settings and expose them in a UI.
• You can put a generation step in CI with a diff check (git diff --exit-code after generating), so drift fails the build rather than silently shipping.
• The team is comfortable owning a small dependency: MIT, dev-time only, but ~39 stars and a single-maintainer risk profile. Budget a 1–2 day spike to confirm Laravel/PHP version compatibility and pin the version.

Look elsewhere when:

• You have external API consumers or a public API contract — go OpenAPI/schema-first.
• You're a decoupled SPA + separate API team where the contract needs to be negotiated, versioned, and documented for third parties.
• You need vendor support, SLAs, or a large community behind the tooling.
• Your backend is heavy on API Resources / DTOs rather than raw Eloquent attributes — the generated surface may not match what you actually expose.
• Your team won't maintain the CI check. Generated types without a drift gate decay into stale types, which is worse than no types because it creates false confidence.

How to Pitch It (Stakeholders)

For executives: A small, free (MIT), dev-time-only utility that removes a recurring class of bugs — frontend code calling backend fields and routes that no longer exist. It's low risk: it adds no production runtime dependency, its output is plain TypeScript files committed to the repo, and removing it is a one-line change. Cost is roughly a 1–2 day spike plus a CI step; the return is fewer late-stage defects and less back-and-forth between frontend and backend on every schema change.

For engineering: One generation step produces TypeScript types for Eloquent models, named routes, and Spatie Settings, so the frontend contract is derived from source instead of re-typed by hand. Wire generation into CI with a clean-diff check to make contract drift a build failure. Note the caveats honestly: it's a low-adoption package (single-maintainer risk), it's optimized for Inertia monoliths, and it won't fit a schema-first/OpenAPI setup. Treat it as an internal convenience with an easy exit — the escape hatch is falling back to hand-written types or OpenAPI, and the migration cost is low because nothing in production depends on it.