Taxonomy Laravel Package

Technical Evaluation

Architecture fit

mibo/taxonomy is presented as a standalone PHP library for taxonomy concerns — vocabularies, term hierarchies, and presumably term attachment to domain objects. For a Laravel codebase the fit is plausible but unproven: the package makes no stated commitment to Laravel idioms (service provider, publishable config/migrations, Eloquent relationship types), so it may be framework-agnostic in a way that forces manual wiring, or it may be Laravel-coupled without saying so. Either is workable, but neither is confirmed. The functional surface a taxonomy library needs is narrow and well understood — nested-set or adjacency-list storage for term trees, polymorphic linking of terms to models, slugging, and tree query helpers — which is good news for substitutability and bad news for differentiation.

Integration feasibility

The signal here is thin and uniformly negative: 0 stars, 0 dependents, no community validation, and a composite score of 0.2. That is not proof of poor quality, but it means the entire due-diligence burden shifts onto us. Before any commitment we need to answer, from source rather than documentation: does it declare Laravel/PHP version constraints, does it publish release tags or only dev-master, is there a test suite that runs in CI, and does it ship migrations or expect us to write schema. The "mibo" vendor namespace with a repo under a separate 4513 org suggests a library extracted from internal work rather than a maintained product — a common and legitimate origin, but one that correlates with abandonment after extraction.

Technical risk

• Bus factor 1 with no evidence of a second contributor. No issue history or release cadence to inspect means no way to gauge responsiveness.
• Version-lock risk. We are likely on a current Laravel major; an untagged package pinned to dev-master can break on an unrelated upstream change with no changelog to warn us.
• Schema lock-in. A taxonomy schema is stateful and expensive to re-model once terms are attached to production records. Getting the storage strategy wrong is a data migration, not a refactor.
• Silent correctness failure. Tree libraries fail quietly — nested-set boundaries drift, subtree moves corrupt, orphaned pivots accumulate. Without tests we inherit that risk untested.
• License and provenance are clean (MIT), so legal exposure is not a blocker.

Key questions for the maintainer (or for source review)

1. Is it Eloquent-specific or framework-agnostic, and which Laravel/PHP versions are supported in practice?
2. What is the storage model — adjacency list, nested set, closure table, or materialized path — and does it support atomic subtree moves?
3. Does it provide polymorphic term attachment, and are pivot rows cascade-deleted on parent model deletion?
4. Are migrations published or owned by the package? Any table-name collision risk with existing schema?
5. Test coverage and last commit date; are there tagged releases with semantic versioning?
6. Does it handle multi-vocabulary taxonomies, or only a single flat term set?

Verdict: do not adopt on current evidence. The domain is small enough that the build cost is measured in days, and the ecosystem already covers it (see below), so the value of an unvalidated dependency is close to zero while its carrying cost is not.

Integration Approach

Stack fit

If we proceed, the correct posture is vendor behind an adapter. Define an internal TaxonomyService contract in our domain layer (attachTerm, termsFor, subtree, move), bind the package behind it in a service provider, and forbid domain code from referencing package classes directly. This caps the blast radius of abandonment at one adapter file and one migration, and it lets us swap to spatie/laravel-tags (flat tagging), kalnoy/nestedset (tree storage on our own model), or staudenmeir/laravel-adjacency-list (recursive CTE traversal) without touching business logic. In practice most Laravel teams land on "our own terms + termables tables with kalnoy/nestedset for hierarchy," which is roughly what this package would give us minus the uncertainty.

Migration path

There is no migration from the package because there is no incumbent — this is greenfield or a replacement of ad-hoc category columns. Sequence it as: (1) spike the package on a scratch branch against a copy of the real schema, seeding 10k terms across 4 levels deep; (2) measure subtree-move correctness and query counts for tree render; (3) if it passes, write the adapter and ship the schema; (4) if it fails, the spike artifacts convert directly into a first-party implementation. Budget the spike at 2–3 days, not 2–3 weeks.

Compatibility

Unresolved until source review. Treat Composer constraint resolution as the first gate — if it cannot install cleanly alongside our current Laravel and PHP constraints without --ignore-platform-reqs or constraint widening, stop there. Widening our own constraints to accommodate a zero-star dependency is a bad trade.

Sequencing

Do not put this on a critical path. It should not be scheduled in the same cycle as a schema migration that other teams depend on, and it should not be introduced during a release freeze window.

Operational Impact

Maintenance

Assume we own it. With no dependents and no visible release cadence, upstream fixes should be modelled as "won't happen." That means we need a fork-ability check: can a mid-level engineer read the source in an afternoon and patch it? If the answer is no, the effective maintenance cost is a rewrite, and we should just do the rewrite now. Add the package to the dependency review list and pin to a commit SHA, not a branch.

Support

No vendor, no SLA, no community. Internal support is whoever integrates it, and that knowledge is a single point of failure unless the adapter contract is documented. Write a one-page ADR recording why the package was chosen over alternatives — future maintainers will otherwise assume it was load-bearing and be afraid to remove it.

Scaling

Taxonomy reads are cheap and cacheable; taxonomy writes are the risk. Tree restructuring under concurrency (two admins moving subtrees) can corrupt adjacency or nested-set storage without explicit locking. Before production, verify: subtree move is transactional, term attachment is idempotent, and reads of a full tree are a bounded number of queries rather than N+1 per node. If the package offers no eager-loading story, a deep taxonomy will become a render-time bottleneck and we will end up caching the whole tree ourselves — at which point the library is doing very little for us.

Failure modes

• Abandonment — most likely; mitigated by the adapter and pinning.
• Schema corruption on move — highest severity; mitigated by integration tests over subtree operations.
• Orphaned pivot rows on model hard-delete — mitigated by database-level foreign keys with cascade, not application-level cleanup.
• Dependency conflict blocking a future Laravel upgrade — mitigated by low coupling and a willingness to fork.
• Silent behaviour change from a dev-master update — mitigated by SHA pinning.

Ramp-up

Low in absolute terms — the domain is intuitive and the API surface should be small — but the absence of documentation means the real ramp is "read the source," which is unpredictable. Estimate half a day for a competent Laravel engineer if the code is clean, and treat a messy read as an early abort signal.

Recommendation: reject for production use. Run a 2–3 day spike only if a specific requirement (multi-vocabulary hierarchy with polymorphic attachment) is genuinely underserved by kalnoy/nestedset plus a pivot table; otherwise build the ~200 lines directly and keep the dependency count flat.