Tag Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a tagging capability. The package is a compact, readable reference for the "many tags on any entity" data model — a Tag entity, a polymorphic Tagging join, a TagManager service, and query helpers. Reading it turns a vague roadmap item into an estimable one: roughly one to two engineer-days for a native implementation in Laravel, which makes "buy" or "fork" hard to justify on cost alone. Use it to price the build, not to avoid it.

• Scope framing for taxonomy features. It supports the first rung of the ladder only: free-form labels attached to records, listed and filterable by name. Tag management UI, autocomplete, synonyms, hierarchies, weighting, per-tenant scoping, and faceted search are all out of scope and belong to a separate epic. This is the single most useful PM artifact here — tagging looks like a one-week feature and faceted search is a quarter; this package cleanly draws the line between them.

• Data model lock-in review. Adopting a polymorphic join table (taggable_type / taggable_id) is a semi-permanent decision that shapes query complexity, reporting, and cascade-delete behavior. The package illustrates the flexible-but-slower option and its known weakness: no foreign keys, so orphaned taggings accumulate and must be cleaned by application logic. That's a deliberate choice worth recording in the design doc.

• Use-case triage. Well supported: CMS content categorization, user-generated labels, campaign/segment tagging, internal admin filtering. Poorly supported without extra work: faceted navigation, tag governance/moderation, co-occurrence analytics, i18n label sets.

• Dependency-risk register entry. 75 stars and zero dependents is a textbook "reference implementation, not a dependency" signal. Low opportunity score plus no downstream validation means no security patching and no community safety net. That assessment feeds the technical-debt and vendor-risk log regardless of whether we ever install it.

• Platform-fit correction. The request frames this as a Laravel/PHP package. It is a Symfony bundle with Symfony 2.x-era constraints. It will not install or function in a Laravel app. The PM action item is to redirect the team to spatie/laravel-tags or a native morphToMany implementation, and to fix the assumption at the intake stage so it doesn't recur in future evaluations.

When to Consider This Package

Consider it when:

• You are on Symfony with Doctrine ORM (legacy 2/3 era) and the bundle's conventions match the surrounding app.
• You need a straightforward many-to-many tagging relation with no hierarchy, synonyms, weighting, or i18n.
• You want a worked example of the Doctrine mapping, listener, and repository query patterns before writing your own. For most teams this — reading, not installing — is the actual value.
• You are prepared to vendor or fork the code and own it indefinitely, with a named maintainer and a budget line.

Look elsewhere when:

• You are on Laravel. It's a Symfony bundle; no service provider, no Eloquent support, and Composer constraints will not resolve. Use spatie/laravel-tags (maintained, Eloquent-native, first-class polymorphic support) or write a thin morphToMany model + trait.
• You are on modern Symfony (5/6/7). Bundle registration, DI conventions, PHP constraints, and Doctrine ORM 3's removal of legacy API surface all break this.
• You need anything beyond basics: tag hierarchies, aliases, weighted or scoped tags, tag merging, autocomplete endpoints, per-tenant tagging, faceted search.
• You need a maintained dependency. Zero dependents, dormant upstream, no vendor, no issue triage, no PHP 8.x guarantees.
• Adoption would require ignoring platform requirements. Force-installing with --ignore-platform-reqs or package aliasing produces an untestable runtime and is a stop sign, not a workaround prompt.

How to Pitch It (Stakeholders)

To executives: Tagging is a small, well-understood feature and we can ship it without a third-party dependency. This specific library is an old Symfony bundle with negligible adoption — 75 stars, no downstream users, no active maintainer — and it will not run on our Laravel stack. Its real value is as a design reference: it shows us the schema and the service shape, which lets us estimate a native build at roughly one to two engineer-days. Recommendation: fund a short spike to read it, then build in-house or adopt a maintained Eloquent package. That removes a maintenance liability and keeps us free to extend into faceted search later.

To engineering: It's a Doctrine entity-tagging bundle — a Tag entity, a polymorphic Tagging join, a Taggable trait/interface, an event-subscriber listener, and a TagManager with loadTagging/saveTagging plus repository query helpers. The pattern is clean and worth half a day of reading, particularly the "write via tag names, read via tag entities" idiom and the listener-driven reconciliation on flush. But it's Symfony-only, pinned to Symfony 2.x and PHP 5.3+, unmaintained, and has zero dependents, so we'd be adopting code we fork on day one. Plan: extract the schema and the TagManager semantics, then implement natively — spatie/laravel-tags on Laravel, or a thin Doctrine taggable trait plus listener if we're on Symfony. Specific things to carry over: a unique constraint on (tag_name, resource_type, resource_id), normalization on write to prevent "PHP" / "php " / "Php" duplicates, eager loading to avoid N+1 on list views, indexed tag_name lookups, and an explicit cleanup path for orphaned taggings since the polymorphic join carries no foreign keys. Treat it as documentation, not a dependency.

Ask: approve a two-day spike (schema + API survey, plus a throwaway Composer resolution attempt to close the compatibility question definitively), with the build-vs-adopt decision made at the end of the spike, and with UI work and any data migration sequenced last since those are reversible and the schema is not.