Tomato Model Generator Laravel Package

Technical Evaluation

Architecture fit. tomatophp/tomato-model-generator is an authoring-time Artisan tool, not a runtime library. It installs via Composer, registers a service provider through auto-discovery, and emits plain Eloquent artifacts — model classes, a matching migration, $fillable/$casts scaffolding, and belongsTo/hasMany wiring. From a delivery standpoint that is the favorable shape: it lives entirely on the developer workflow side of the build, so it cannot add request-path latency, cannot become a production dependency, and cannot create an availability failure mode. The blast radius of adoption is engineering hours and code quality — not uptime, not customer impact. That materially lowers the cost of being wrong.

The tradeoff is that it competes in an already-served category. Native make:model -mfsc, Blueprint-style schema tools, and hand-rolled internal generators all solve the same problem. The package's proposition is not a new capability but a faster, more convention-enforcing path through an existing one, and only inside the TomatoPHP/Filament ecosystem does that framing carry real leverage. The TPM question is therefore not "is this good software" but "does our roadmap contain enough repeated CRUD admin surfaces for per-entity savings to compound into something worth a dependency."

Integration feasibility. Mechanically low; behaviorally unverified. The install path is composer require, confirm provider discovery, php artisan list | grep -i tomato, then a first generation run. That is an afternoon. The gate that actually matters is whether the output matches our conventions, and that cannot be assessed without running the generator against a representative schema and reading every generated line.

Three uncertainties drive the estimate. First, there is no published command reference in the supplied material — the real API surface has to be reverse-engineered from src/Console and src/Generators, so the team's understanding is inferred rather than contracted. Second, the description names only models and migrations, while the surrounding assessment notes claim factories, soft deletes, and publishable config/stubs; that discrepancy must be settled against source before anyone plans around it. Third, TomatoPHP packages commonly assume a specific Filament major version, so a panel-integration failure is plausible even when the core generator works. All three are cheap to check now and expensive to discover mid-sprint.

Technical risk. The dominant risk is evidence, not engineering. 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, no external bug surface working in our favor, and no way to know what changed without diffing src/ ourselves. Treat v1.0.1 strictly as a maintenance signal — it is not evidence of capability and should not anchor a roadmap commitment.

The secondary risks are generic generator risks, each of which surfaces after engineering time is committed: relationship inference is best-effort and will mishandle composite keys, polymorphic relations, and custom column types; generated files landing in App\Models can collide with existing models that carry hand-written casts, accessors, scopes, or traits; unpublished or unpinned config can silently change output on upgrade; and at 1.0.x, minor bumps may still alter stubs or command signatures. None are exotic, but each converts an "easy install" into a scoped spike rather than an assumed-away detail.

Key questions.

• What actually changed in v1.0.1 versus v1.0.0, and does the diff touch stubs or generated output?
• What are the composer.json constraints — PHP version, Laravel 9/10/11, and a required Filament major?
• Does it introspect an existing database (pulling doctrine/dbal or similar), or generate purely from interactive prompts?
• Is there a dry-run or target-directory option, so it could serve as a CI drift check rather than a file writer?
• Are stubs publishable and overridable, and is that extension point public or internal?
• Does it actually emit factories and soft deletes as the assessment notes claim, or only models and migrations?
• Who maintains it, what is the commit cadence, and what does issue-response history look like?
• Can output be cleanly separated from the tool if the package is abandoned next quarter? (Almost certainly yes — which bounds the downside.)

Integration Approach

Stack fit. Strong inside the target context, weak outside it. The leverage case is a team already on — or deliberately standardizing on — Laravel plus Filament/TomatoPHP, building internal tools and back-office CRUD where the schema is young and moving. There, each additional entity costs less than the last and stub-driven convention enforcement becomes a governance benefit. Outside that context — customer-facing surfaces with bespoke UX, non-CRUD domains, event-sourced or policy-heavy systems — the generated scaffolding becomes dead weight almost immediately, and native make:model -mfsc is the better answer. Do not adopt this as an isolated library pick; it belongs in the same conversation as the admin-panel stack decision.

Migration path. Low-friction and reversible by design, because the output is plain Laravel code we keep regardless of whether we keep the tool. Recommended path: install into a scratch namespace (App\Models\Generated), generate against one real entity, diff against the hand-built equivalent, and only then decide whether to standardize. Write down the policy before rollout — either "generated files are read-only, customization lives in traits/subclasses" or "generator output is a one-time bootstrap" — and commit it alongside the config. Ambiguity on that one rule is precisely what turns a productivity tool into a merge-conflict generator. Because there is no runtime coupling, removal is composer remove with zero production consequence; state that explicitly in any approval memo so vendor risk stays a bounded objection rather than an open one.

Compatibility. Verify before spending evaluation time: PHP constraint, supported Laravel majors, and whether a specific Filament major is required. Pin to ^1.0 and publish + commit config and stubs on day one so defaults cannot shift silently on upgrade. If the team is on a Filament version the package does not target, expect panel-integration features to fail at boot even though the generator itself runs — that is the most likely first-install failure and the cheapest to pre-empt. Semver discipline at 1.0.x is not the same contract as a mature 5.x release; treat every bump as potentially output-changing until diffed.

Sequencing. Four steps, each with a defined exit. (1) Verify — composer.json constraints, source diff of v1.0.0...v1.0.1, enumerate Artisan commands, confirm which artifacts are actually emitted. Half a day. (2) Spike — 1–2 days generating one representative entity with deliberately awkward features: a foreign key, a non-standard or composite key, a custom column type. Measure against the hand-built baseline. (3) Decide — standardize, restrict to internal tooling, or fall back to native generators. (4) Codify — document the generation command in onboarding, commit config and stubs, and set the regeneration policy before any second developer uses it. Do not sequence this in parallel with active schema churn on the same models.

Operational Impact

Maintenance. Minimal runtime maintenance — it is not deployed, so there is nothing to patch in production. The real carrying cost is provenance: with one undocumented patch release and no external contributors, we are effectively maintaining a vendored opinion. Budget for someone owning stub and config drift, and pin the version. The recurring cost that surprises teams is review, not upgrades: generated code is a starting point, never a merge without reading, and that review line item does not shrink on its own.

Support. There is no support contract, no SLA, and no adoption community to lean on — zero stars and zero dependents means the answer to "has anyone hit this" is usually no. Internal capability has to substitute: one engineer who has read src/Generators and can reason about the stubs, plus a documented fallback to native generators if the package stops working. That is a survivable position precisely because the output is standard Laravel, but it should be an explicit staffing assumption rather than an implicit one. Escalation for anything touching a production model goes to the owning engineer, not upstream.

Scaling. Scaling is organizational, not infrastructural — there is no capacity ceiling. Value scales with entity count and team size: at one or two entities it barely justifies the dependency; at a standing backlog of admin-only requests, or across several squads that need consistent model structure, the compounding effect is the entire business case. The countervailing scaling risk is divergence — without committed stubs, each developer's local defaults drift and the consistency benefit evaporates exactly when headcount grows. Standardize or don't adopt.

Failure modes. Four to plan for. Silent mis-generation: relationship inference skips or misreads a composite key and the model looks plausible but is wrong — mitigate with a required review checklist on generated relationships. Collision/overwrite: a regeneration clobbers hand-written casts, scopes, or traits — mitigate with the scratch namespace and an additive-only rule. Upgrade drift: a patch bump changes stub output with no changelog — mitigate by pinning and diffing before any bump. Abandonment: the maintainer stops shipping — impact is bounded to losing the tool, not the code, so the mitigation is documentation rather than contingency engineering. Note that none of these reach production without a human merge, which is the package's best structural property.

Ramp-up. Roughly half a day per developer. The interactive prompt flow is discoverable without documentation, so onboarding cost is low; the cost that is not low is calibrating judgment about what to accept from the output, which only comes from comparing generated artifacts against hand-built ones. Practical ramp plan: one engineer completes the spike and writes a short internal note covering the command, the namespace convention, the regeneration policy, and the three things the generator gets wrong on our schema. That note — not the package README — is what the rest of the team will actually use, and it is the cheapest durable artifact to come out of the evaluation.

Recommendation. Timebox a 1–2 day spike on a non-critical internal tool, measured against the hand-built baseline on three numbers: cycle time per entity, post-generation corrections required, and share of generated files surviving first review untouched. Standardize only if it wins clearly and the team is committed to the Filament/TomatoPHP stack. If either condition fails, keep native generators and revisit when the CRUD backlog justifies it.