Taxonomy Laravel Package

Product Decisions This Supports

• Taxonomy as a first-class domain, not a bolt-on. Classification (categories, tags, vocabularies, hierarchical terms) drives navigation, search facets, SEO landing pages, recommendations, and content governance. This package represents the "reuse an existing taxonomy layer" option in that decision.
• Build vs. buy vs. borrow. The real decision this informs is whether to (a) model taxonomy ourselves in Eloquent, (b) adopt a mature package (e.g., spatie/laravel-tags, kalnoy/nestedset for hierarchies), or (c) start from a small MIT library like this one and own the fork. mibo/taxonomy is only credible as a starting point or reference implementation.
• Scope framing for the roadmap. Whether taxonomy is a v1 requirement (catalog/CMS/marketplace with faceted browse) or a v2 concern. A small PHP library lowers the cost of pulling taxonomy forward if it covers our term/vocabulary model.
• Use cases it maps to: content categorization and editorial workflows, product catalog and merchandising hierarchies, documentation/knowledge-base structure, and tag-based retrieval for search or recommendations.
• Evidence gap to flag: with 0 stars, 0 dependents, and a low composite score, there is no adoption signal. We cannot validate its API surface, hierarchy strategy (adjacency list vs. nested set vs. closure table), multi-tenancy, or Laravel integration from metadata alone. Treat every capability claim above as to be verified by reading the source before it influences a roadmap commitment.

When to Consider This Package

Consider it when:

• Taxonomy is an isolated, low-blast-radius concern in the product — a supporting capability, not a core differentiator.
• We want a small, forkable starting point under a permissive license (MIT), and we're comfortable owning maintenance.
• The team can absorb the vetting cost: read the source, confirm the storage model, check for migrations, tests, and PHP/Laravel version constraints.
• We need a portable PHP library rather than a framework-coupled one — useful if the classification layer might outlive a single Laravel app.
• Timeline pressure makes a time-boxed spike cheaper than a from-scratch design.

Look elsewhere when:

• We need maintenance guarantees, security responsiveness, or vendor support — none are evidenced here.
• Community and ecosystem signals matter to stakeholders or to our risk model (0 stars, 0 dependents, no downstream users to learn from).
• Requirements include large-scale hierarchies, multi-tenancy, permissions on terms, translations, or versioned taxonomies — assume these are absent until proven otherwise.
• We need deep Laravel-native ergonomics (policies, factories, Nova/Filament resources, queue-aware reindexing). A mature, actively maintained package is the safer default.
• A bespoke schema is genuinely small for us — a terms table plus a polymorphic pivot often beats any dependency, and removes an abandonment risk entirely.

How to Pitch It (Stakeholders)

To executives: Taxonomy will be needed regardless of vendor choice; the question is only how much we build. This library is MIT-licensed and small, so the downside is bounded — the cost is engineering diligence time, not license fees. But it is unproven: no stars, no downstream users, no maintenance track record. Recommendation is a fixed-effort spike (1–2 days) to evaluate it against a mature alternative or a 100-line in-house schema, then decide. Do not let it become a dependency of record without that step.

To engineering: This is a candidate for a reference implementation or a fork, not a library we adopt on faith. Please confirm: storage model for hierarchies, migration story, test coverage, supported PHP/Laravel versions, and whether it is framework-agnostic by design. If the surface is small, forking and owning it may be lower risk than depending on an unmaintained package.

Framing to avoid: presenting this as a "solution." It is an option to evaluate. The decision it feeds is build-vs-buy for a supporting capability — and the answer may well be "neither; we model it ourselves."