Spatie Laravel Tags Plugin Laravel Package

Technical Evaluation

Architecture fit. This is not a standalone library — it is a read-only subtree split of a component that ships inside filament/filament. Its entire job is to adapt spatie/laravel-tags to Filament's form and table component APIs (SpatieTagsInput, and by extension the table column). Architecturally it assumes two things are already true or acceptable: a Filament v5 panel is the admin surface, and tag persistence is owned by Spatie's tags + taggables polymorphic schema. If our application already standardizes on Filament, this is a near-zero-friction fit. If tagging is a domain concept we intend to model ourselves (workflow states, taxonomy with hierarchy, per-tenant scoping), the package imposes Spatie's schema on us and is the wrong starting point.

Integration feasibility. Genuinely low effort. Three steps: composer require ... -W, publish the Spatie tags migration, add HasTags to the target model. Then SpatieTagsInput::make('tags') in a resource. There is no service provider configuration, no config file of our own, no custom persistence layer.

Technical risk. Concentrated in dependency management, not code:

• Lockstep versioning. ^5.0 must track the Filament major. The plugin has no independent release cadence — upgrading Filament upgrades this. That is convenient but removes our ability to defer a plugin change independently of a core upgrade.
• The -W flag. composer require -W permits transitive dependency rewrites. In a mature application this can silently move Laravel or Spatie versions. This should be a reviewed, isolated commit, never bundled with feature work.
• Metric distortion. 40 stars and 0 dependents are artifacts of the subtree-split packaging; real-world usage flows through filament/filament, which is widely deployed. Do not read this as a low-adoption signal, but equally do not read it as evidence of battle-testing for this surface area.
• Schema co-ownership. Publishing Spatie's migration puts a vendor-owned table into our migrations directory. Any customization (indexes, tenant column, UUID keys) is now a fork we maintain.
• Truncated security note. The README's section on tag types and privilege namespaces is cut off in the excerpt. That section appears to govern who can assign which tag types — directly relevant if tags drive authorization or content classification. This must be read in full before adoption.

Key questions for the team:

1. Is tag data a user convenience (free-form labels) or a governed taxonomy? The answer determines whether free-text creation should be disabled.
2. Do tags need tenant scoping? Spatie's default schema is global; multi-tenancy requires a custom tag model and migration changes.
3. Does the privilege-namespace mechanism in the README's security section map onto our existing policy layer, or does it introduce a second authorization model?
4. Are we willing to accept the Filament-v5 floor, including its PHP and Laravel requirements, as a hard constraint?

Integration Approach

Stack fit. Laravel + PHP 8.2-or-later with Filament v5 panels, alongside spatie/laravel-tags (v4 line). The plugin adds no runtime services, no queues, no external calls — it is request-path UI code only.

Migration path. Two scenarios:

• Greenfield tagging: publish the Spatie migration, run it, add HasTags to the models that need it, then attach SpatieTagsInput to the relevant Filament resources. Nothing to unwind.
• Existing tagging outside Filament: if the application already uses Spatie Tags via API or front-end forms, this is additive — the same tags/taggables tables are shared, and Filament becomes another writer. Verify that existing write paths and this component agree on tag types, since type mismatches present as "tags silently not showing up."

If we have a bespoke tagging implementation already, this is a data migration project, not a package install, and should be scoped as such.

Compatibility. The main constraint is the Filament major. Pin Filament explicitly, run the -W install on a branch, and inspect the resulting composer.lock diff before merging. Confirm the plugin's SpatieTagsInput supports the same customization surface as Filament's native tags input (the README claims parity) — any divergence becomes a UX inconsistency between tagged and untagged resources.

Sequencing for a first increment:

1. Spike on a branch: install, publish migration, inspect the generated schema, confirm no collision with existing tables.
2. Apply HasTags to a single low-risk model.
3. Wire one resource with SpatieTagsInput::make('tags')->type('...') — use an explicit type from day one rather than the untyped default; retrofitting types later means backfilling a type column.
4. Validate the full lifecycle: create, edit, detach, delete-tag-with-existing-pivots, and search/filter behaviour in the table listing.
5. Add the corresponding table column and confirm query count (see Operational Impact).
6. Roll out resource-by-resource. This is a per-resource change; there is no big-bang cutover and no reason to attempt one.

Operational Impact

Maintenance. Because the repository is a read-only subtree split, we cannot patch it locally — fixes and features must land upstream in filamentphp/filament and arrive via a Filament release. Operationally this means: our maintenance burden is "keep Filament current," not "maintain a tags plugin." The corollary is that we have no lever if upstream declines a change we need; our only recourse is replacing the component with a custom Filament field, which is a small but real piece of work.

Support. Community support only — GitHub issues on the monorepo and Filament's Discord. The authoritative documentation for the data layer is Spatie's, not Filament's, so debugging spans two projects and two documentation sets. If the organization requires a commercial support path, that must be sourced at the Filament level, not here.

Scaling. Two considerations:

• Query behaviour. Tag rendering in tables fans out across the taggables pivot. Without eager loading, a 50-row index page produces 50 additional queries. This is the single most likely production performance issue and is easily caught with a query-count assertion in a test.
• Vocabulary growth. The component allows users to create tags inline by default. Across many users and months, this reliably produces near-duplicates (customer-success, Customer Success, cs). At small scale it is cosmetic; at large scale it degrades filtering and reporting. Mitigation is configuration, not code: constrain suggestions, disable free creation for governed taxonomies, and assign tag types deliberately.

Storage itself is not a concern — tags are a low-cardinality, high-read dataset and the schema handles it comfortably.

Failure modes to watch:

Ramp-up. Effectively nil for anyone who has built a Filament resource — it is a drop-in field, and the Spatie-side prerequisites are documented. Realistic onboarding is under a day, including reading the Spatie docs. The genuine cost is not developer learning time; it is the governance decisions that precede adoption: taxonomy vs. free-text, tenant scoping, type namespacing, and tag lifecycle policy. Those should be settled with the product owner before the first resource is wired, because each one is cheap now and expensive after data exists.