Tagging Bundle Laravel Package

Product Decisions This Supports

• Feature scoping: free-form tagging vs. structured taxonomy. Tagging looks like a one-sprint feature and is not: it forces decisions on controlled vocabulary vs. open tagging, tag normalization/merging, synonyms, i18n of labels, and whether tags feed search, navigation, or SEO. This bundle encodes one specific answer (open tagging, polymorphic taggable join, tag-cloud weighting via FabienPennequin/DoctrineExtensions-Taggable). Reading it is a cheap way to pressure-test your own requirements before you commit a roadmap slot.
• Build vs. buy — and the answer here is build. At 10 stars, 0 dependents, and a last release of April 2014, this is not a vendor choice; it is an architecture reference. The decision it supports is "we own tagging as first-party domain code," with the bundle used only as a schema sketch: Tag entity, polymorphic taggable relation, weight/count for cloud rendering.
• Dependency and supply-chain posture. Adopting it pulls in an equally dormant transitive dependency and will trip Composer's abandoned-package warning. That is a concrete input to your "no unmaintained runtime dependencies" policy and to any security review gate — useful as a cited precedent even if you never intended to ship it.
• Legacy migration triage. If any product surface still runs Kunstmaan CMS bundles (Symfony 2.x era), this flags a known tech-debt item: tagging is one of several features that will need re-implementation or replacement during a framework upgrade. That belongs in the migration backlog with an owner, not in a "someday" list.
• Roadmap sequencing for content discovery. Tagging is the cheapest precursor to related-content, topic hubs, and faceted browse. This bundle's tag-cloud/weighting model is a reasonable MVP shape for those downstream features — useful for sizing the follow-on work rather than the first release.

When to Consider This Package

Consider it only in three narrow cases:

1. You are already inside the Kunstmaan bundle stack, pinned to Symfony 2.x / PHP 5.x, and already shipping DoctrineExtensions-Taggable. In that world it is a thin, MIT-licensed convenience layer that saves wiring time — and even then, verify it against your exact bundle versions before installing.
2. As a read-only reference during design. If you are writing a tagging ADR, the entity/relation shape here is a legitimate starting point. Clone it, do not require it.
3. As evidence in a deprecation argument. If someone proposes "just use the existing tagging bundle," the release date and dependent count settle the conversation quickly.

Look elsewhere — decisively — if any of the following are true:

• You are on Laravel. This is a Symfony/Kunstmaan bundle; despite the "Laravel/PHP" framing, it will not install or function in a Laravel application. Use spatie/laravel-tags or a small first-party implementation instead.
• You are on a maintained Symfony version (5/6/7) or PHP 8.x. The package predates PSR-6, Symfony Flex, and modern Doctrine, and its transitive dependency is unmaintained. Expect to fork and rewrite, at which point you have built it anyway.
• Tags are user-facing at scale. The 2014 model has no answer for tag merging at volume, moderation, abuse, or per-locale labels — all of which you will need by month three.
• You need search or analytics integration. Tags must feed your search index and reporting; that integration is yours to build regardless of what this bundle provides.

How to Pitch It (Stakeholders)

To executives: We evaluated a ready-made PHP component for tagging and recommend against adopting it. It was last released in 2014, has essentially no active user base, and depends on another dormant library — the maintenance risk exceeds the roughly one to two weeks of engineering it would save. Tagging will be built in-house as a small, owned module. Total incremental cost is low; the alternative is a permanent liability in our dependency tree. The evaluation itself was inexpensive and de-risks a feature that is frequently underestimated.

To engineering: Treat kunstmaan/tagging-bundle as a design document, not a dependency. We are taking its entity model (tag + polymorphic taggable join + weight) as a starting reference and implementing it natively in our stack — with proper normalization, per-locale labels, and merge/rename support from day one. Note also that it is Symfony/Kunstmaan-specific, so it is inapplicable to our Laravel services; that mismatch alone closes the question.

Ask: Approve in-house tagging as a scoped work item (design + build), and record "no unmaintained runtime dependencies" as the standing rationale so this assessment does not need to be repeated for the next dormant bundle that surfaces.