Weave Code
Tomato Model Generator Laravel Package
tomatophp/tomato-model-generator
Tomato Model Generator scaffolds Laravel Eloquent models, generating fillable fields, relationships, and migrations to speed up CRUD setup in the Tomato PHP admin panel and keep model code consistent across your Filament resources.
Eloquent Model Generator
Frequently asked questions about Tomato Model Generator
- What does tomatophp/tomato-model-generator actually do?
- It is an authoring-time Artisan generator that scaffolds Laravel Eloquent models, emitting a model class, a matching migration, fillable and casts scaffolding, and belongsTo/hasMany relationship wiring. It is designed to speed up CRUD setup in the Tomato PHP admin panel and keep model code consistent across Filament resources. It is not a runtime library, so it does not affect request-path performance or production availability.
- How do I install tomato-model-generator in a Laravel app?
- Install it with composer require tomatophp/tomato-model-generator, then confirm the service provider is registered through Laravel package auto-discovery. Run php artisan list and grep for tomato to see the commands the package exposes. The install itself is quick, but you should still verify the command surface and generated output against your own conventions before relying on it.
- Does it support Laravel 11 and which Filament version is required?
- The supplied material does not confirm Laravel or Filament version constraints, so check the package composer.json for PHP, Laravel 9/10/11, and required Filament major version before planning around it. TomatoPHP packages often assume a specific Filament major, so a panel-integration failure is plausible even when the core generator works. Run a quick spike against your target Laravel and Filament versions rather than assuming compatibility.
- What files does the generator create for a new model?
- The core output is an Eloquent model class with fillable fields, casts scaffolding, and relationship methods, plus a matching migration. The surrounding notes also mention factories, soft deletes, and publishable config or stubs, but the short description only names models and migrations. Settle that discrepancy by reading src/Console and src/Generators before you plan around those extra artifacts.
- Is tomato-model-generator safe to use in production?
- Yes, in the sense that it is a developer-workflow tool rather than a runtime dependency, so it cannot add request latency or become an availability failure mode. What ships to production is the generated Eloquent and migration code, so review every generated line as you would hand-written code. Treat the package itself as a dev-time convenience and pin it in require-dev where appropriate.
- Can it infer relationships and generate migrations automatically?
- Relationship inference is best-effort, which means it will likely mishandle composite keys, polymorphic relations, and custom column types. Generated migrations are a starting point and should be read before they run against a real schema. Always diff the output against your intended schema and correct the belongsTo and hasMany wiring manually where needed.
- How does it compare to php artisan make:model -mfsc?
- Laravel's native make:model flags already generate a model, migration, factory, seeder, and controller, and hand-rolled internal generators or Blueprint-style schema tools solve much of the same problem. This package's value is a faster, more convention-enforcing path through an existing capability, and that leverage is strongest inside the TomatoPHP and Filament ecosystem. Outside that ecosystem, evaluate whether the per-entity time savings justify an extra dependency.
- What are the maintenance and versioning risks?
- The package has zero stars, zero dependents, a 0.33 composite score, and a single v1.0.1 release dated 2024-03-28 whose notes are a bare compare link with no described changes. That means no peer adoption to learn from and no way to know what changed without diffing src yourself. Treat v1.0.1 as a maintenance signal, not evidence of capability, and pin config and stubs because minor bumps at 1.0.x may still alter output or command signatures.
- Will it overwrite or conflict with existing models in App\Models?
- Generated files land in App\Models and can collide with existing models that carry hand-written casts, accessors, scopes, or traits. Before running it on a real project, check whether the command supports a dry-run or target-directory option so you can inspect output before writing. Commit or back up your models first, then diff the generated files against what already exists.
- Does it introspect an existing database schema or only use interactive prompts?
- The available material does not say, so check src/Console and src/Generators to see whether it pulls doctrine/dbal or a similar schema reader, or generates purely from interactive prompts. That distinction changes how much manual field definition you will need to supply. There is no published command reference in the supplied material, so the real API surface has to be reverse-engineered from source.
Weaver
How can I help you explore Laravel packages today?