Weave Code
Laravel Model Typescript Transfomer Laravel Package
nolanos/laravel-model-typescript-transfomer
Generates TypeScript definitions for Laravel Eloquent models via spatie/laravel-typescript-transformer. Maps database column types to TypeScript, respects hidden/visible fields, handles nullable columns, and works with php artisan typescript:generate.
Generate Typescript definitions for your Eloquent models
Frequently asked questions about Laravel Model Typescript Transfomer
- What does nolanos/laravel-model-typescript-transformer actually do?
- It is a thin adapter for spatie/laravel-typescript-transformer that generates TypeScript definitions for Laravel Eloquent models. It contributes a collector and a transformer to Spatie's existing pipeline, then maps your database columns to TypeScript types when you run php artisan typescript:generate. The heavy lifting of config loading, filesystem output, and artisan wiring is delegated to the Spatie package.
- How do I install and configure this package in a Laravel app?
- Install it with composer require nolanos/laravel-model-typescript-transformer, then edit config/typescript-transformer.php. Append Nolanos\LaravelModelTypescriptTransformer\ModelTypeScriptCollector to the collectors array and Nolanos\LaravelModelTypescriptTransformer\ModelTransformer to the transformers array. After that, run php artisan typescript:generate to produce the definitions.
- Which Laravel and PHP versions are supported?
- The README does not list explicit Laravel or PHP version constraints; it depends on spatie/laravel-typescript-transformer v2 or later, so your supported Laravel versions follow that package's requirements. Check the composer.json constraints of both packages before upgrading. Because this is a thin wrapper, a Spatie major release can strand it until the collector and transformer interfaces are updated.
- Does it respect $hidden and $visible on Eloquent models?
- Yes. The ModelTransformer reads the model's database columns and then filters them through the model's $hidden and $visible properties, so fields excluded from serialization are excluded from the generated TypeScript. This approximates what your API returns but does not account for $appends, accessors, or API Resources.
- How are nullable columns and database types mapped to TypeScript?
- Column types are mapped with a fixed table: strings, UUIDs, dates, and text become string; integer, bigint, float, decimal, and numeric become number; boolean and bool become boolean. Nullable columns get a | null suffix. Unknown database types map to unknown with a comment showing the original DB type.
- Does it generate relationship types like belongsTo or hasMany?
- No. The transformer produces flat properties only, so belongsTo, hasMany, and other relationship shapes must be written by hand. That reintroduces manual work if your frontend depends on embedded relationships. It fits best when a model's serialized payload really is a flat row.
- Does it support $appends, accessors, casts, or API Resources?
- No. The package derives types from the database schema, not from what your API actually returns, so $appends, custom casts, accessors, and API Resources are not represented. If those layers define your contract, the generated types are only adjacent to useful. Teams with DTOs or Resources often end up with a second, weaker source of truth.
- Can I run typescript:generate in CI without a database?
- Schema introspection needs a live, reachable database at generation time, so CI must provision MySQL or Postgres or run migrate:fresh before typescript:generate. There is no offline or cached mode documented. Plan for that in your build job if you want a generation gate.
- How do I keep the generated TypeScript from going stale after migrations?
- Nothing forces regeneration after a migration, so types drift silently. Add a CI step that runs php artisan typescript:generate followed by git diff --exit-code to fail when committed types are stale. That gate is the only reliable way to detect drift.
- Is it production-ready, or should I write my own collector?
- Treat it as pre-adoption code: the repository has very few stars, a single author, and no dependents, and the package name itself is misspelled. Pilot it on a few representative models and diff the output against hand-written types. If that diff is small, a roughly 150-line in-house collector against Spatie's interface may be the safer build-versus-buy choice.
Weaver
How can I help you explore Laravel packages today?