Laravel Typescript Transformer Laravel Package

Product Decisions This Supports

• Keeping frontend and backend contracts in sync — the core decision this package de-risks. If we run a Laravel API with a TypeScript frontend (Inertia, Vue, React, Svelte), the transformer makes our PHP DTOs, enums, and controller signatures the single source of truth and emits the matching .d.ts files. That lets us decide to stop maintaining hand-written interfaces, which is where most contract-drift bugs originate.
• Build vs. buy for our type layer — the alternative is writing and maintaining TS types by hand, or publishing an OpenAPI schema and running a separate generator. This package is the low-effort buy option: one Composer dependency, a service provider config, and a generation command.
• Frontend architecture choices — whether to standardize on spatie/laravel-data DTOs and native PHP enums as our API shape becomes much easier to justify when those choices automatically yield typed clients. Conversely, if we have no DTO layer, this package has little to transform.
• Route helper strategy — v3's typed route helper generation (autocompletion for route names and parameters) is a separate, concrete decision: keep using magic strings in the frontend, or adopt generated, compile-checked route() calls.
• CI and developer workflow design — a decision to run generation in CI and fail on a dirty diff turns contract drift into a build failure rather than a production bug. Watch mode supports the local-dev half of that workflow.
• Roadmap scoping for API-contract work — this can replace or shrink an initiative to "document and type our API," and it should be evaluated against an OpenAPI-first roadmap item rather than in isolation.

When to Consider This Package

Adopt when all of the following hold:

• Backend is Laravel 10+ on PHP 8.2+ (v3 dropped older versions), and the frontend is TypeScript.
• We have real PHP structures worth transforming — DTOs, enums, value objects, FormRequests, controller signatures — not just arrays.
• Contract changes are frequent enough that hand-maintained types are a recurring source of bugs or review friction.
• The team will accept a codegen step in CI or the build pipeline, and generated files have a defined home and owner.

Look elsewhere when:

• We need runtime validation, not just types. This package emits types only; it does not validate payloads at runtime. Pair with Zod (or similar) or look elsewhere if runtime parsing is the goal.
• The API is public or consumed by third parties. Then OpenAPI (with openapi-typescript or equivalent) is the better contract artifact — it serves external consumers, docs, and non-TS clients.
• The backend is not Laravel, or we are pinned below Laravel 10 / PHP 8.2.
• The frontend is not TypeScript, or the app is a small Blade-only surface where the generation step costs more than it saves.
• We cannot own the generated output. Watch mode and generation must be treated as real infrastructure; teams that won't wire it into CI will get stale types and false confidence.

Adoption risk to price in: 400 stars and essentially no public dependents means thin external battle-testing. It is Spatie-maintained with a healthy release cadence through Laravel 13, but v3 was a full rewrite (config moved from a config file into a service provider), and recent patch releases are still fixing route/controller generation edge cases — root-route helpers, install-command provider detection, watcher crashes. Treat route and controller generation as newer than the DTO/enum transformers and validate it in a timeboxed spike before committing broadly.

How to Pitch It (Stakeholders)

To executives: We can make the PHP backend the single source of truth for our TypeScript frontend with one MIT-licensed dependency from Spatie, a vendor we already trust. It removes a whole category of "the API changed and the frontend didn't" bugs, and it reduces the manual effort of writing and reviewing types on every API change. Cost is near zero; the main investment is a generation step in CI, which is a few hours of engineering.

To engineering: spatie/laravel-typescript-transformer walks our marked PHP classes, enums, controller actions, and routes and emits generated TypeScript types and a typed route() helper. We annotate with #[TypeScript], run the generation command (or watch mode locally), and get compile-time feedback in the frontend the moment a PHP property or endpoint signature changes. It integrates with laravel-data, handles unions, generics, native TS enums, and nullability conventions. We should adopt it incrementally: start with enums and DTOs, add controller and route generation after a spike, and gate it in CI so a stale diff fails the build. It is types-only — we still need a runtime validation layer in the frontend, so we should pair it with Zod rather than treat it as a replacement.

One-line ask: Approve a one-sprint trial — spike the DTO and enum transformers on one feature area, measure the hand-written types we delete, then decide on broader rollout and the CI gate.