Oi Laravel Ts Laravel Package

Product Decisions This Supports

• Frontend/backend contract strategy for Laravel + TypeScript products. The package generates TypeScript interfaces from Eloquent models, relationships, casts, and spatie/laravel-data-style DTOs. This supports choosing an Inertia.js, Vue, React, or Svelte frontend where model shapes closely match API payloads.
• Roadmap prioritization. If a TypeScript client is strategic, fund a short pilot to validate generated types in CI and developer workflows. If the roadmap is API-first, multi-client, or public-API oriented, prioritize OpenAPI/GraphQL schema generation instead.
• Build vs. buy. Buy/integrate when the backend is Laravel-only (PHP 8.2+, Laravel 11–13) and the team can accept an MIT-licensed, early-stage community package. Build only if requirements exceed the package: versioned API contracts, breaking-change detection, field-level authorization shapes, runtime validation, or multi-backend support.
• Use cases with best fit. Internal tools, admin dashboards, prototypes, and Laravel/TypeScript monorepos benefit most. DTO support helps teams already using spatie/laravel-data patterns. Namespace filters, UUID/ULID key typing, watch mode, and relationship support reduce hand-written type drift.
• Decisions this does not support. It is not a runtime validator, API documentation generator, authorization model, or cross-language contract system. It should not be positioned as a replacement for OpenAPI, GraphQL, or zod-style runtime validation.

When to Consider This Package

Consider it when:

• The backend is Laravel-only and the frontend is TypeScript, especially with Inertia.js or a shared repository.
• Eloquent models and DTOs are the practical source of truth for frontend payload shapes.
• The team needs faster iteration and is willing to inspect generated output, pin versions, and run generation in CI.
• Relationship interfaces, custom casts, DTO/enum literals, namespace filters, and UUID/ULID primary keys materially reduce manual type maintenance.
• A small, senior team can self-support and contribute fixes if needed.

Adoption criteria before committing:

• Validate output against real API responses and edge cases, especially nullable fields, data_replaces_model, and relationships pointing to replaced models.
• Confirm compatibility with the target Laravel/PHP versions and existing frontend tooling.
• Add a CI check that regenerates types and fails on unexpected diffs.
• Treat the package as an evaluated dependency, not a platform: it has useful documentation, changelog, releases, and a reported test suite of 142 tests/344 assertions, but only 1 GitHub star, 0 dependents, and a low overall score. Those are weak external validation signals.

Look elsewhere when:

• The organization requires vendor support, SLAs, security review, or long-term maintainer guarantees.
• The product exposes a public API or supports multiple backend services; use OpenAPI, GraphQL, protobuf, or another schema-first contract.
• Runtime validation, API documentation, or authorization-aware response shaping is required.
• The team cannot tolerate bus-factor, low adoption, or potential breaking changes in an early-stage package.
• A mature, widely adopted generator or an existing internal contract pipeline already exists.

How to Pitch It (Stakeholders)

Executive summary: This package can reduce manual TypeScript type maintenance and lower frontend/backend integration errors for Laravel + TypeScript products. It is MIT-licensed, installs via Composer, and generates interfaces from Eloquent models, relationships, casts, and DTOs. The business case is developer productivity and fewer contract mismatches, not new revenue. The main risk is maturity: very low adoption, one visible maintainer, and no dependents. Approve only as a time-boxed pilot in a non-critical application, with a fallback to OpenAPI generation or a small internal generator.

Engineering summary: The package provides php artisan oi:gen-ts, watch mode, configurable output, namespace inclusion/exclusion/extension, DTO generation, enum literal unions, custom props, and UUID/ULID-aware primary keys. It integrates by generating a .ts file that can be committed or checked in CI. Reported test coverage is a positive signal, but low stars/dependents mean we should pin the version, review generated diffs, and avoid coupling critical contracts without an exit plan.

Decision requested: Run a one-week pilot with clear success criteria: generated types compile, cover our main models/relationships/DTOs, produce acceptable diff noise, and fit CI. If successful, adopt behind a pinned version with an internal owner; if not, fall back to OpenAPI-based generation or a custom Artisan command.