Taxonomies Bundle Laravel Package

Product Decisions This Supports

• Taxonomy data-model decision: whether to model catalog/content categorization as a hierarchical tree of taxons (nested set), with per-locale translations and multiple independent taxonomies attached to one entity. The bundle encodes one proven answer to that question — useful as a reference design even if the code isn't adopted.
• Build vs. buy for categorization: a "buy/reuse" data point for teams already on the Sylius/Symfony stack. Category trees, slugs, nesting, and parent/child CRUD are commodity work; this package is evidence that the feature should never be a roadmap line item.
• Use cases it maps to: storefront navigation and merchandising menus, product-to-category assignment, brand/collection/tag taxonomies, and any many-to-many tagging where hierarchy matters.
• Stack-fit gate (the actual decision): this is a Symfony2 bundle, not a Laravel package. The first PM decision it drives is "does our framework match?" — for Laravel the answer is no, and the evaluation ends there.
• Roadmap de-risking: treat it as a pattern library, not a dependency. Copy the model (Taxon + TaxonTranslation + nested-set ordering), not the package.

When to Consider This Package

Consider it only when:

• You are maintaining a legacy Symfony 2.x / early Sylius (0.x–1.x) application that already pulls Sylius bundles and needs the taxon model without a rewrite.
• You need a canonical reference implementation of a translatable, hierarchical taxonomy to port into your own codebase.
• You are building a throwaway internal prototype on PHP 5.6/Symfony 2.8 with no internet-facing exposure.

Look elsewhere when:

• You are on Laravel. No bridge exists, the ORM assumptions are Doctrine (not Eloquent), and integration cost exceeds reimplementation. Use kalnoy/nestedset plus spatie/laravel-tags.
• You are on modern Symfony. Use the maintained sylius/taxonomy-bundle, or gedmo/doctrine-extensions Tree / knplabs/doctrine-behaviors for the tree mechanics alone.
• Maintenance signal matters. 0 stars, 0 dependents, no releases, no CI badge, Sylius-monorepo-split era code (~2013–2016). No PHP 8 support, no Symfony 5/6 support, no security advisory path. That is a supply-chain and audit finding, not a nit.
• You need i18n, admin UI, permissions, or API exposure out of the box. The bundle gives you the entity model; everything else is yours to build.
• Procurement or compliance requires maintained dependencies with a named owner and a patch cadence.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is an abandoned component from the early Sylius ecosystem, not a strategic dependency. It solves a real, common problem — hierarchical product categories — but the code has had no maintenance for roughly a decade and has zero downstream users, which makes it a durability and security risk rather than a shortcut. My recommendation is no-go for adoption as a dependency; we may reuse its data model as a design reference at no cost and no risk. The build-cost saving it appears to offer is illusory once migration, patching, and audit overhead are counted.

To engineering (the actionable version): Symfony2-era bundle, Doctrine nested-set implementation, last touched in the Sylius monorepo split. Do not add it to composer.json. If we're on Sylius, use the core taxonomy bundle. If we're on Laravel, this is the wrong ecosystem — pair kalnoy/nestedset with spatie/laravel-tags and move on. If we must touch it for a legacy system, vendor the code, pin the commit, wrap it in our own tests, and document the exit path in the same ticket that introduces it.