Laravel Tags Laravel Package

Product Decisions This Supports

• Feature scoping for "tagging" as a cross-cutting capability. The package answers a recurring product question — "can users tag anything (articles, products, tickets, media, customers) from one UI?" — with a polymorphic many-to-many design. That tells you tagging can be a platform-level primitive rather than a per-feature bolt-on, which changes how you sequence the roadmap (ship it once, reuse everywhere) instead of rebuilding labels for each new module.
• Build vs. buy, with a third option: "buy as blueprint." MIT license and a small surface area mean the cost of evaluating is hours, not sprints. But the archive status converts the decision from adopt into fork or copy the schema. The realistic play is a timeboxed spike to harvest the migration/relationship design, then either adopt a maintained alternative or write ~150 lines in-house.
• Commoditization signal for prioritization. 29 stars and 0 dependents is a strong market signal: tagging is solved, undifferentiated, and not a place to spend engineering differentiation budget. Route the roadmap energy to the tagging experience (autocomplete, tag merging, facets, governance) rather than the persistence layer.
• Concrete requirement validation from the bundled features. Sluggable + Translatable out of the box maps directly to two roadmap asks product teams actually file tickets for: SEO-friendly tag archive URLs (/tags/laravel) and localized tag names for multi-market launches. Its presence confirms these are table-stakes expectations, so scope them into the tagging epic from day one rather than as v2 polish.
• Data model and migration decisions. The taggables pivot pattern, tag-type grouping, and slug uniqueness constraints are the decisions that are expensive to reverse later (duplicate tags, orphaned pivots, collation issues on unique slugs). Reviewing this package's schema is a cheap way to pressure-test yours before the first migration ships.
• Use-case fitment across the portfolio. Good candidates: CMS/blog content tagging, e-commerce product tags and filter facets, support-ticket labels, CRM segmentation tags, media-library keywords. Poor candidates: hierarchical taxonomies, tag analytics/trending, or anything needing strict audit trails.

When to Consider This Package

Consider it (narrowly) when:

• You are on an older Laravel/PHP version that the package's constraints still satisfy, and you have a small platform team comfortable owning vendored code.
• You specifically need translatable tag names and slugs without wiring two more packages together — the bundled Sluggable/Translatable integration is the package's most distinctive selling point.
• You need polymorphic tagging across several models and want a reference implementation to copy rather than a dependency to install.
• Blast radius is genuinely small: internal tooling, an admin-only back office, or a prototype where a CVE in a tag library is not a compliance event.

Look elsewhere when:

• It is unmaintained. Archived means no security patches, no Laravel 11/12 compatibility work, and no fixes when a PHP minor version breaks a type declaration. Any adoption plan must include a named internal owner and a fork.
• You need a support contract or an SBOM-friendly dependency. Zero dependents means zero community pressure to fix things; you are the only one who will ever file that issue.
• The dependency chain expands. Rinvex packages typically pull in rinvex/laravel-support, and the sibling cortex/tags line is heavier still. Audit the transitive tree before committing — a "small" package that drags in three archived siblings is not small.
• Your needs are richer than flat tags. Tag merging/deduplication, hierarchy, synonyms, faceted search, or tag-level permissions are all out of scope here.
• A maintained alternative fits. spatie/laravel-tags is the default comparison: active maintenance, large install base, translatable tags, and a track record of Laravel major-version support. For most greenfield work, this is the correct answer and the Rinvex package is the design reference.
• Your tagging needs are genuinely simple. A tags table, a taggables pivot, and a morphToMany trait is a half-day of work with zero external risk. If you do not need slugs or translations on day one, in-house wins on total cost of ownership.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed tagging library that would let us add "tag anything" functionality quickly, including SEO-friendly tag URLs and localized tag names. However, the project is archived — no vendor, no security updates, no support. My recommendation is not to add it as a dependency. Instead, we spend one engineer-day reviewing it as a design reference and then build or buy a maintained equivalent. Cost is negligible; the value is de-risking a schema decision that is expensive to change later, and avoiding an unmaintained package in our supply chain that would show up in any security review.

To engineering: It does polymorphic tagging across any Eloquent model via morphToMany, and ships Sluggable and Translatable support out of the box — that combination is the reason to look at it. The reason not to install it: archived upstream, 29 stars, zero dependents, and a transitive dependency on rinvex/laravel-support. Recommendation is a one-day spike to lift the migration and relationship patterns, followed by a short build-vs-buy call against spatie/laravel-tags. Either way we own the outcome; we just do not want to own someone else's abandoned code.

Decision requested: Approve a one-day spike. Do not add rinvex/laravel-tags to the dependency manifest.