Laravel Eloquent Tags Laravel Package

Product Decisions This Supports

• Build vs. buy for tagging: Tagging/labeling is commodity functionality. This package gives polymorphic many-to-many tagging (one tags table + one polymorphic pivot) for any Eloquent model — posts, products, users, documents — without us owning the schema, sync logic, or query scopes. That is a "buy" (adopt) decision, not a build decision, unless we need capabilities it doesn't cover (see below).
• Feature scoping — "tags v1" vs. "tag platform": This package supports the thin version of the feature: attach/detach/sync tags, query models by tag, list a model's tags. If the roadmap item is "let users label content and filter by label," this is sufficient. If the roadmap implies tag groups, tag translations, tag hierarchies, or tag-driven SEO pages, this package alone will not get us there and we should scope accordingly.
• Cross-entity reuse: Because tagging is polymorphic, the same capability can be exposed on multiple resources with one dependency and one migration. That reduces the marginal cost of "add tags to X too" requests later — useful when arguing for a single shared tagging primitive instead of per-feature label columns.
• Roadmap risk / vendor durability: The 1.x milestone is a positive signal — the maintainer has committed to a stable public API under semver, which is the point at which we can safely depend on it. Counterweight: this is a single-maintainer package with a small community footprint. For a long-lived product surface, that's a maintenance-risk input to the build-vs-buy call, not a blocker for a first iteration.
• Upgrade-cost estimation for the 1.x line: The 1.1.0 delta is dominated by CI/dependency housekeeping (Dependabot bumps for actions/cache, codecov-action, setup-php, actions/checkout, coding-standard constraint widened to ^4.0) plus internal style/table-name fixes. For us, that translates to near-zero integration cost and a maintainer actively tending the repo. One item does touch the public configuration surface — removal of the taggable_morph_key option — which is a config-shape change we'd need to account for if we had already customized the morph key. We have not adopted yet, so there is no migration burden, but it's a reminder to pin the version and read the changelog before minor bumps.

When to Consider This Package

Adopt when most of the following hold:

• You need simple, polymorphic tagging across one or more Eloquent models and nothing more elaborate.
• You want a lightweight dependency — small surface area, few transitive requirements — rather than a full tagging framework.
• Your app is on a modern Laravel/PHP baseline supported by the 1.x line, and you're comfortable pinning to a 1.x constraint.
• You value CI hygiene and release cadence as a proxy for maintenance health; this repo shows automated dependency updates and coverage reporting.
• Your team would otherwise spend a sprint re-implementing tag CRUD, pivot syncing, and "find all posts tagged X" queries — i.e., the feature is not a differentiator.

Look elsewhere (or build) when:

• You need tag groups, tag translations/i18n, tag hierarchies, synonyms, related-tag suggestions, or tag-weighted search — evaluate a fuller package or a dedicated taxonomy/search service instead.
• You need enterprise-grade support, SLAs, or a large contributor base — a single-maintainer dependency is a poor fit for a business-critical, hard-to-replace surface.
• You require audit trails, moderation workflows, or per-tag permissions; those are product concerns this package won't model for you.
• The removal of configuration options in a minor release (e.g. taggable_morph_key) is a signal that the config surface is still settling. If you plan to lean heavily on customization, prefer a package with a longer stability record or budget for reading changelogs on every bump.
• You'd be adding a second tagging mechanism alongside an existing one — consolidate instead.

How to Pitch It (Stakeholders)

For executives: Tagging is a small, well-understood feature that users expect and that we should not be paying engineers to reinvent. A mature Laravel package now covers it, and this release marks its arrival at a stable 1.x API — meaning we can depend on it with a version constraint and expect predictable upgrades. The release itself is almost entirely maintenance: the maintainer is keeping dependencies current and CI green, which is exactly the signal we want from a small dependency. One minor configuration option was removed, so the integration work is a version pin plus a changelog check on upgrades. Cost is measured in hours, not sprints.

For engineering: Adopt zingimmick/laravel-eloquent-tags at a ^1.1 constraint for polymorphic tagging. You get tag attach/detach/sync and tag-based queries against any model with one table pair. Note two things before integrating: (1) the taggable_morph_key config option was removed in 1.1.0 — don't build around it, and confirm defaults match our intended morph key; (2) the 1.1.0 diff is predominantly Dependabot CI bumps and coding-standard updates with a table-name fix, so there's no feature work to evaluate and nothing to backport. Before committing, do a 30-minute comparison against spatie/laravel-tags on the dimensions we actually need (tag groups, translations, community size, upgrade history) — this package wins on footprint and simplicity, and loses on ecosystem breadth. If we only need "label and filter," take this one.

Risk note to carry forward: single-maintainer dependency — pin the version, subscribe to releases, and keep the tagging abstraction behind a thin application-level service so swapping it out later is a contained change rather than a refactor.