Product Decisions This Supports
- Build vs. buy for catalog taxonomy: This package supplies the data-model and hierarchy layer (taxonomies → taxons, tree/nested-set structure, slugs, parent/child relationships) that otherwise consumes 1–3 engineering weeks to design, implement, test, and document. It converts "how do we structure the catalog?" from an architecture debate into a configuration exercise.
- Catalog and navigation IA: Multi-level category trees drive primary navigation, mega-menus, sitemaps, and SEO-friendly layered URLs. This directly supports go-to-market features (findability, organic traffic) rather than back-office plumbing.
- Categorization as a cross-cutting capability: Because it is framework-level rather than commerce-specific, the same primitives support product categories, content sections, help-center topics, marketplace vendor verticals, or any parent/child taxonomy — one mental model for the whole product surface.
- Roadmap sequencing: If the roadmap contains facets/filters, collection merchandising, or multi-store catalogs, adopting a proven taxonomy model now avoids a painful migration later. Hierarchy-aware queries (descendants, subtree filters) are the substrate for those features.
- Vendor/architecture posture: Choosing the Vanilo family (rather than a bespoke model or a heavier PIM/SaaS) is a strategic bet on an open, MIT-licensed, Laravel-native stack — a "keep the core in-house, buy the boilerplate" move.
- Make-vs-extend on adjacent features: Category-level merchandising, per-category content blocks, and breadcrumb generation become small extensions on top of a stable base instead of greenfield work, which clarifies what the team actually needs to build to differentiate.
When to Consider This Package
Consider it when:
- You are on Laravel/PHP and the domain has any hierarchy: commerce catalog, content sections, marketplace verticals, knowledge base, or a multi-level menu.
- You need nested-set or tree semantics — descendant queries, subtree filtering, depth, ordering — not just flat tags.
- You are already in, or evaluating, the Vanilo ecosystem; the marginal integration cost is near zero and the contracts align with the product/catalog modules.
- You want MIT-licensed, in-repo, Eloquent-native taxonomy you can fork, extend, or audit — with no per-SKU SaaS fees.
- You need slug-based routing and SEO-friendly URLs without building routing, slug generation, and uniqueness handling yourself.
- You expect small, stable surface area: a few models, traits, and migrations. Low blast radius, easy to read in an afternoon.
Look elsewhere when:
- Non-Laravel or non-PHP stack — irrelevant.
- Your taxonomy is genuinely flat (a single
category_id column and a dropdown). The nested-set machinery is unnecessary complexity and an extra migration/query-pattern to learn.
- You need faceted, multi-dimensional, attribute-heavy classification (many-to-many facets, per-channel assortments, localized per-market trees). That is PIM territory; a Laravel module will become the wrong tool quickly.
- You need merchandising/editorial workflow — scheduling, approvals, staging, preview, bulk re-parenting at scale. Those are product features, not taxonomy models.
- Support and longevity risk is unacceptable. The split package shows very low standalone adoption (9 stars, 0 listed dependents). Caveat: for monorepo-split packages, stars and dependents accrue to the parent
vanilo/framework, so this is not proof of abandonment — but it does mean you cannot lean on a large third-party community, Stack Overflow corpus, or ecosystem of companion packages. Do due diligence on the parent repo's commit cadence, issue responsiveness, and release history.
- You require a vendor SLA, security program, or formal LTS. MIT + maintainer-dependent support means you own the fork risk.
How to Pitch It (Stakeholders)
To executives: This is a small, MIT-licensed Laravel component that supplies the category-hierarchy layer of a catalog — the parent/child structure, URLs, and navigation data behind product browsing and site search. It is a buy-the-boilerplate, own-the-differentiators decision: it removes roughly 1–3 engineer-weeks of undifferentiated model, migration, routing, and test work, and it keeps us on an open-source stack with no licensing cost and no data lock-in. The trade-off to name explicitly is support concentration: it is maintained as part of the Vanilo ecosystem rather than by a broad third-party community, so we should treat it as code we may need to maintain or fork. Recommendation framing: low cost, low switching cost, contained risk — the code is small enough that an exit is measured in days, not quarters.
To engineering: Eloquent-native models and contracts (taxonomies and taxons with a nested-set tree), slug handling and route binding, and a trait for making any model categorizable — so it drops into an existing Laravel app without a bespoke subsystem. Small, readable surface area; forkable under MIT; aligns cleanly with the Vanilo product/catalog modules if we go further into that stack. Confirm against current source: supported Laravel/PHP version range, tree library dependency (e.g., nested-set package), migration publishing, and interface stability across minor releases. Note that low standalone stars/dependents reflect monorepo splitting, not necessarily health — verify against the parent repository's release and issue activity before we commit.
To product/design: It gives us real hierarchy primitives — arbitrary depth, ordering, parent/child navigation, slug-based URLs — and keeps taxonomy independent of commerce, so the same structure can back navigation, landing pages, and content sections. It does not give us merchandising workflow, editorial approvals, or faceted filtering; those remain roadmap items we build or buy separately.