Tomato Products Laravel Package

Technical Evaluation

What a TPM is actually buying. tomatophp/tomato-products is a Filament admin module for the TomatoPHP stack, not a commerce engine and not a headless catalog API. It ships product/category/pricing/stock CRUD, media handling, translatable fields, and a published schema. For a TPM, the leverage is concentrated in time-to-admin-surface: a working catalog back office in days rather than weeks, at the cost of binding to a small, single-vendor ecosystem. Frame the decision internally as "buy an admin UI, inherit a schema," not "adopt a product platform," so stakeholders do not infer commerce capability that is not there.

Architecture fit. High fit only where the application is already Laravel + Filament + the surrounding TomatoPHP core (users, permissions, translations, settings). Low-to-moderate fit elsewhere — the package's value lives in its Filament resources and its assumptions about adjacent Tomato modules, not in a framework-agnostic domain model. It is explicitly not a fit for API-first/headless storefronts without an adapter layer, and out of scope for pricing rules, tax, order orchestration, or inventory reservation.

Integration feasibility. Mechanically low: composer require, publish config/migrations, migrate, register the Filament plugin, seed permissions. The real effort is a boundary decision made before the first migration runs: does the package own the product catalog (downstream ERP/storefront/PIM written against its tables), or does it bootstrap an admin surface we progressively wrap? The package's tables become shared state the moment migrate executes, and migrating away later is a data project, not a config change.

Technical risk.

• Release opacity (highest-likelihood, low-severity): v1.0.18 is a patch bump with an auto-generated compare link and no changelog. Every upgrade is untriageable without a source diff — a durable, recurring cost.
• Inherited framework coupling (highest-severity): hard dependence on Filament and tomatophp/* core. Filament major transitions (v3 → v4) historically break plugin packages; our admin-panel upgrade timeline is partly outside our control.
• Schema ownership: migrations ship in vendor. Local edits imply a permanent fork burden or migration-order conflicts on upgrade.
• Maturity: 1.0.x with rapid patches — actively maintained but not stabilised; no published semver/deprecation policy.
• Ecosystem gravity / bus factor: 2 stars, 0 dependents, small ecosystem. Weigh against the support horizon, not against today's functionality.
• Multi-tenancy: not assumed; per-tenant catalogs require global scopes and migration work, pushing toward fork-or-extend.

Key questions for the maintainer/vendor.

1. What changed in v1.0.18, and will a changelog + semver policy exist going forward?
2. Which Filament major is supported, and is a v4-compatible release planned and dated?
3. Is the product schema stable public API, or may table/column names change in minor releases?
4. What is the minimum supported Laravel/PHP/Livewire matrix, and which tomatophp/* packages are hard dependencies?
5. Are migrations package-owned or meant to be published and edited — i.e. the documented upgrade path for schema changes?
6. Maintenance model: single maintainer, commercial support, or community? Is there an SLA?

Integration Approach

Stack fit gate. Approve the spike only if the target app is already on Laravel + Filament and cannot justify building admin CRUD from scratch. If the app is API-first, or if variants/multi-currency/multi-store/multi-tenant are near-term requirements, stop here — retrofitting those onto a flat product table is the expensive path.

Migration path.

1. Spike with production-shaped data. Install v1.0.18 in a throwaway branch, generate the panel, and read src/Models/Product.php and database/migrations/ — the migrations are the source of truth for column names, not the UI. Seed thousands of SKUs with categories/media, because Filament table performance gaps surface only at volume.
2. Pin exactly. composer require tomatophp/tomato-products:1.0.18; do not float ^1.0. With no changelogs, automated dependency updates (Dependabot/Renovate) are unsafe here.
3. Declare the schema a shared contract. Extend the model in App\Models rather than editing vendor code; add fields via a companion one-to-one table rather than altering vendor migrations. Preserves upgradeability at near-zero cost.
4. Insert an adapter layer. Repository/service classes between the package models and every downstream consumer (storefront, ERP, PIM, reporting). A day or two of work that converts a future replacement from a data migration into a re-implementation of the admin surface.
5. Reuse, don't reinvent, the resource. Mirror the Filament resource's rules() and form schema in our own API/form endpoints so admin-created and API-created records stay consistent.
6. Wire permissions into the existing roles model rather than standing up a parallel one.

Compatibility. Validate four constraints explicitly on the production matrix: Laravel version, PHP version, Filament major, Livewire version. Test in CI on the exact production PHP/Laravel pair — this family of packages most often fails on those boundaries, not in application logic.

Sequencing. Week 1: spike + schema validation on production-shaped data. Week 2: adapter layer, permission wiring, admin smoke test in CI. Week 3: downstream integration against the adapter only. Defer anything variant/multi-store until the boundary and adapter are in place — not the other way round.

Operational Impact

Maintenance. The recurring cost is upgrade review, not upgrades. With no changelogs, every bump requires diffing database/migrations/ and src/ between tags, plus an admin smoke test. Budget roughly half a day per upgrade and assign a named owner; a small MIT package with zero changelog discipline will accumulate drift silently otherwise. Treat package tables as an integration boundary and schedule a quarterly dependency review so Filament/Laravel upgrades are planned, not forced.

Support. None formally — community-only, single-vendor, 2 stars, 0 dependents. The internal owner is the support contract. Staff for that reality: designate a package owner, document the version pin and review routine, and keep the adapter layer in place so support exposure is bounded by surface area, not by hope.

Scaling. Admin-side scalability is the open question: Filament resources with eager-loading gaps and missing indexes may degrade on catalogues in the hundreds of thousands of SKUs. Validate with production-shaped data before committing. The package does not attempt inventory orchestration, so high-volume stock movement and reservation logic must live elsewhere. Multi-tenant, multi-store, and multi-currency are not assumed and become our problem — budget for global scopes and migration work if any of these are near-term.

Failure modes (ranked by likelihood × impact).

• Silent behaviour change in a minor/patch release — mitigated by exact pinning, source diffs, and CI smoke tests.
• Blocked Filament major upgrade — inherited from the ecosystem; mitigate by not extending vendor resources in ways that make patching harder, and by tracking upstream Filament status on the roadmap.
• Schema-ownership conflict — vendor migrations clashing with local edits; mitigated by companion tables and App\Models extension rather than vendor edits.
• Bus factor / abandonment — mitigated by the adapter layer and by treating the schema as replaceable rather than foundational.

Ramp-up. 1–2 days for a Filament-fluent Laravel developer; roughly a week for someone new to Filament — the learning cost is Filament, not this package. Add half a day of onboarding for the upgrade-review routine so the ownership doesn't sit with one person by default.