Spatie Laravel Tags Plugin Laravel Package

Product Decisions This Supports

• Build vs. buy for tagging: Tagging shows up in nearly every content-heavy roadmap (articles, products, support tickets, assets, contacts). This package lets us ship it as a configuration task rather than a custom feature — composer require, publish the tags migration, prepare the model, add SpatieTagsInput::make('tags') to the form and a matching column/table filter. That is a days-not-sprints delta versus building tag CRUD, pivot tables, autocomplete, and validation ourselves.
• Feature scoping and phasing: Because tag storage and semantics come from the mature spatie/laravel-tags library and only the admin UI comes from this plugin, we can commit to a thin v1 (flat tags on one model) and expand later (typed/grouped tags via ->type('categories')) without a schema rewrite. That makes tagging a safe "yes" in a release even when the long-term taxonomy is still undecided.
• Roadmap and platform alignment: This is a first-party Filament plugin, so adopting it is really a decision to standardize on the Filament + Spatie stack for the admin surface. It reinforces a "one panel, one conventions set" architecture rather than accumulating bespoke admin widgets.
• Use cases it unlocks cheaply: content categorization and editorial curation, faceted filtering/browse in admin tables, customer or asset segmentation, internal labeling for support/ops triage, and campaign or project grouping — all with a consistent, accessible input UX our users already recognize from other Filament fields.
• Risk and maintenance budgeting: The package is a read-only subtree split of the main filamentphp/filament monorepo. That means the code is maintained upstream alongside the core framework — good for longevity — but also that our version cadence is coupled to Filament major releases (currently ^5.0). Budget for that upgrade path rather than treating this as an independent dependency.
• Security/access-control decisions: The README explicitly calls out tag types and privilege namespaces. That is a product-level input: if tag types will map to roles or tenants, we should decide the namespace scheme before launch, not retrofit it after tags exist in production.

When to Consider This Package

Adopt when most of these are true:

• The product already runs (or is committing to) Filament v5 for its admin/back-office surface.
• We are willing to adopt spatie/laravel-tags as the tagging data model — i.e., flat tags optionally grouped by type, stored in Spatie's tables.
• The requirement is categorization and filtering, not a full taxonomy product: users pick from or create tags, admins browse and filter by them.
• We want form input and table display to stay in sync with minimal custom code, and we want to reuse the standard Filament tags-input behaviors (suggestions, reordering, validation) rather than reimplement them.
• The team is comfortable with Composer, publishing vendor migrations, and adding a trait/interface to Eloquent models.
• Timeline pressure favors shipping a conventional tagging feature now over designing a bespoke one.

Look elsewhere — or plan custom work — when:

• We are not on Filament, or we are pinned to an older Filament major (^5.0 is a hard constraint).
• The domain needs hierarchies, synonyms, merge/dedupe workflows, moderation queues, or tag governance — Spatie types group tags but do not model a tree or editorial workflow.
• Multi-tenancy or fine-grained permissions are central. Type-based privilege namespaces help, but we should validate they map cleanly to our authorization model before committing.
• Tagging is a core differentiator or analytics surface (tag co-occurrence, trending, reporting). At that point the plugin is a UI convenience and the real investment is a data/reporting layer.
• We need a headless/API-first or non-Eloquent tagging capability, or tags must span systems outside this Laravel app.
• Beware reading the repo signals literally: 40 stars and 0 dependents describe the subtree split, not real adoption — usage is counted against filament/filament. Conversely, don't plan to fork or file issues here; the split is read-only and support flows upstream. Evaluate it on the parent project's health, not this repo's.

How to Pitch It (Stakeholders)

To executives: Tagging is a recurring, high-visibility request across content, support, and segmentation use cases. This plugin lets us deliver it as configuration on top of two well-established open-source foundations — Filament (our admin framework) and Spatie's tagging library — instead of a custom build. Expected effort is measured in days rather than weeks, ongoing maintenance is near-zero because the code ships with Filament itself, and it keeps our admin UI consistent rather than adding another one-off screen. The main trade-off to acknowledge is version coupling: we move when Filament moves.

To engineering: Add the package via Composer with -W, publish and run Spatie's tags migration, and prepare the target models per Spatie's docs. Then it is a drop-in SpatieTagsInput in forms and the corresponding column in tables, with full parity to Filament's native tags input — including optional ->type() grouping for tag collections. Two caveats to design around: (1) the README flags tag types and privilege namespaces as a security concern, so agree the namespace/type scheme up front if tags are permission-relevant; (2) this repository is a read-only subtree split of the Filament monorepo — do not fork or patch it locally, and route issues/PRs upstream. Add a smoke test covering create/edit/filter on a tagged model, and treat Filament major upgrades as the trigger to re-verify this integration.

Bottom line: Low-cost, low-risk, high-leverage if we are on Filament and our tagging needs are conventional. If taxonomy governance, hierarchy, or tag analytics become product priorities, revisit and scope a dedicated solution rather than stretching this plugin.