Tomato Category Laravel Package

Product Decisions This Supports

• Feature scoping — ship taxonomy now, cheaply. The package provides a working categories/tags/types system that attaches polymorphically to any Eloquent model, plus the admin CRUD and forms. The decision it unblocks is "do we build categorization into this release?" — and the answer becomes yes-at-low-cost for CMS content, product catalogs, document tagging, help-center topics, or internal asset classification, without commissioning a new schema or admin surface.

• Build vs. buy for admin tooling. Treat it as an adopt-and-vendor accelerator, not a platform dependency. It replaces roughly one to two weeks of migrations, models, controllers, and forms — but only inside the Splade/TomatoPHP admin stack. Outside that stack the buy case collapses; a thin bespoke taxonomy model is cheaper than porting this one.

• Stack standardization. Its value is a data point in the larger question of whether to standardize on TomatoPHP/Splade for internal admin. If Splade is already the admin layer, this is a near-free add-on. If it isn't, this package alone must never be the reason to adopt the stack.

• Roadmap sequencing — validate faceted filtering before paying for search. The type discriminator (category vs. tag vs. type) is a cheap way to prove users actually filter by taxonomy before committing budget to Meilisearch, Typesense, or Elastic. Learn demand first, buy the index second.

• Maintenance-ownership decision. Zero stars, zero dependents, and no release since June 2024 makes adoption a fork-and-own call. That reframes the roadmap line item from "integrate a package" to "vendor the code, assign a named owner, set a review date." Budget the owner; that is the real cost.

• Blast-radius control. Best suited to internal admin panels, back-office tooling, and MVP prototypes where ripping it out later is contained. State explicitly that it does not belong on customer-facing or revenue-critical paths — don't leave that to engineering judgment.

• Locale and content-ops scope. Categories can be translatable, supporting multi-language content plans — but confirm it before promising: translation depends on spatie/laravel-translatable being wired up, and per-locale labels are not a full translation workflow.

When to Consider This Package

Consider it when:

• You are already running Splade / TomatoPHP for admin UI. This is close to a hard precondition — the only context where integration cost is genuinely near-zero.
• You need polymorphic, model-agnostic categories, tags, and types, and want the admin CRUD for free rather than hand-rolling migrations, controllers, and forms.
• You are shipping an internal tool or MVP where speed to demo outweighs long-term dependency risk.
• You have an owner willing to vendor or fork the code and treat MIT-licensed, single-maintainer software as a starting point rather than a supported dependency.
• Your taxonomy needs are shallow — flat lists, simple type grouping, a light parent/child tree. No deep nesting, no term merge/split, no audit trail.
• You can accept no SLA: no community answers, unproven Laravel version coverage, and a release cadence quiet for over a year.

Look elsewhere when:

• You are not on Splade. Filament, Nova, and Backpack have mature taxonomy plugins; spatie/laravel-tags plus a resource is the lighter, better-supported bet.
• You need hierarchical or enterprise taxonomy: nested sets (kalnoy/nestedset), adjacency lists with real tree operations, translated term management, term merging, or audit trails.
• You require support guarantees, security patching, or a vendor who answers tickets. Zero stars and zero dependents mean you are the maintainer.
• The product is long-lived and public-facing, where an abandoned dependency becomes a migration liability at the worst possible moment.
• You need search-grade faceting. This stores classifications; it does not index, rank, or aggregate them at scale.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed accelerator that gives us categories, tags, and types for any content type in our admin panel — roughly one to two weeks of build for the cost of an afternoon's install. It is the cheapest possible way to test whether taxonomy-driven navigation and filtering are worth investing in before we pay for a search backend. The trade-off is explicit: nobody else maintains it, so we own it. That means a named engineer, a pinned version, and a scheduled review — a contained, reversible bet we should keep off revenue-critical surfaces.

To engineering: Read it before you trust it. It is a schema + trait + resource bundle, not a framework: Category model with a string type discriminator, a polymorphic pivot, and a trait over morphToMany. Five files — models, migrations, traits, config, admin resource — de-risk the whole thing in about fifteen minutes. Do three things on day one: enforce a morph map so class renames don't orphan pivot rows, define typed relationships (tags(), categories()) on our own models instead of scattering where('type', ...), and wrap it behind our own interface so swapping to spatie/laravel-tags later stays a contained change. Pin the exact version, add the missing cascade constraints yourself, and write one pivot feature test as our canary for the fork we should assume is coming.