Filament Badgeable Column Laravel Package

Technical Evaluation

Architecture fit. This is a thin presentation-layer add-on, not a domain package. BadgeableColumn extends Filament's own TextColumn, and Badge is a small value object with label(), color(), textColor(), visible(), fontFamily(), weight(), and size() supporting closures. There are no migrations, no service-provider bootstrapping of business logic, no persistence, no auth surface, and no API contract. It renders in both Filament tables and infolists, and works with the Panels package or the standalone Tables package. Adoption therefore commits us to nothing architecturally — the blast radius is one column class and a CSS build step. It is a UX/scanability tool for back-office operators, not a data-modeling one.

Integration feasibility. High. composer require awcodes/filament-badgeable-column, add one @source glob to the theme CSS, and swap individual TextColumn::make() calls for BadgeableColumn::make() with prefixBadges() / suffixBadges(). Because it subclasses TextColumn, existing ->searchable() / ->sortable() chains survive the swap. Realistic effort for a pilot resource: 3–5 dev-days including theme rebuild, eager-load audit, and UX review.

Technical risk. The dominant risk is tight coupling to Filament's TextColumn internals, and the changelog proves it is not theoretical: Filament 4.15/5.10 added parameters to TextColumn::getPrefix()/getSuffix(), which produced a fatal error on load until v3.2.1; Filament 5.7+ changed default state handling and broke rendering until v4.1.0/v3.2.0. The failure mode is "admin tables 500 on a framework minor bump" — high visibility, low detectability by unit tests. Secondary risks: the two-track version matrix (3.x for Filament 4.x with backports, 4.x consolidated for Filament 4.x and 5.x) means a fix can land on the line we are not on; the CSS @source requirement fails silently as unstyled or invisible badges; and the composite score (30.4, opportunity 43.1) with 148 stars, 0 listed dependents, and a single maintainer reflects a bus factor of one, mitigated only by MIT licensing and a surface small enough to fork credibly.

Key questions.

• Which Filament majors are in our estate, and does the 4.x v4/v5 consolidation let one plugin version cover all panels?
• Can we enforce composer lockstep between Filament and this package in a single PR?
• Who owns the custom-theme build, and is adding the vendor @source glob acceptable to platform/DevOps?
• Is badge color the sole carrier of meaning, or is there a redundant label (accessibility)?
• Do operators need to filter/sort/export on what the badge shows? The package is display-only.
• Do we depend on this, or fork and own ~300 lines of Blade plus a column subclass?

Integration Approach

Stack fit. Laravel 12/13 on PHP 8.3–8.4 (current test matrix) with Filament 4.x or 5.x → plugin 4.x. Filament 3.x panels must stay on plugin 2.x; Filament 2.x on 1.x. Legacy panels should be treated as out of scope rather than pinned to abandoned lines.

Migration path. No data migration, no schema change. Convert columns incrementally, one resource at a time; rollback is a one-line revert per column plus composer remove. That reversibility is what justifies piloting rather than a design review gate.

Compatibility and sequencing.

1. Confirm Filament version and that a custom theme already exists (required per Filament styling docs).
2. Add @source '../../../../vendor/awcodes/filament-badgeable-column/resources/**/*.blade.php'; to the theme CSS and rebuild; verify compiled CSS actually contains the badge/color utilities.
3. Pilot one high-traffic resource (order status, user state).
4. Audit the query: closure badges over relationships (the BelongsToMany topics pattern in the README) will N+1 unless ->with([...]) is added — make this part of the conversion checklist, not an afterthought.
5. Pair every meaningful badge with a SelectFilter/TernaryFilter on the same attribute; a visible status the user cannot filter on is a UX regression.
6. Accessibility pass: label + color together, no color-only encoding, dark-mode contrast checked (the changelog shows a prior dark-mode defect, so theme parity is a known weak spot).
7. Record the version-pin and upgrade policy in the team runbook.

Sequencing against platform work. Schedule independently of any Filament major upgrade — that is precisely when the package's overrides break. When Filament does bump, upgrade both in the same PR with a visual QA pass on table pages.

Operational Impact

Maintenance. Low steady state, non-zero. Two live release lines plus backports means subscribing to releases and reading both changelogs each bump. Budget ~1–2 dev-days per quarter, spiking to 1–2 days whenever Filament ships a minor touching TextColumn affixes or state handling.

Support. No vendor SLA. Community GitHub issues, single maintainer. The credible escalation path is fork-and-patch; name one backend owner (column logic) and one frontend owner (theme/CSS) so styling drift does not accumulate unowned.

Scaling. Rendering cost per row is trivial. Real scaling risks are (a) N+1 from closure badges on relationships and (b) badge explosion on wide tables — cap or truncate with a "+N" affordance, and validate at realistic page sizes including Filament's "all records" pagination option.

Failure modes.

• Fatal error on panel load after a Filament minor. Observed twice upstream. Detect with a staging smoke test that loads each table page, not with unit tests.
• Unstyled or invisible badges when the @source glob is missing or assets are stale. Detect with a snapshot test on one table page.
• Export mismatch: CSV/Excel exports will not carry badges, so screen and export diverge. Document, or add a first-party computed column for export.
• Empty/null relations: confirm a closure returning an empty collection renders column text only; add a fixture.
• Palette drift after Filament theme changes; low severity, cosmetic.

Ramp-up. Half a day. Any developer who has written a Filament TextColumn already knows the API. The one footgun to teach explicitly: fontFamily(), weight(), and size() on the column style the column text, while the same calls on Badge style the badge — called in the wrong place you get mis-styled cells, not an error. Also teach the house convention: "if you badge it, filter it."

Verdict. Adopt for internal admin UX if we are already on Filament 4/5 with a custom theme, treating it as a cosmetic, non-load-bearing dependency pinned lockstep with Filament and forkable on short notice. Do not adopt it as the vehicle for anything a user must filter, sort, or export — that is a first-party build, not a plugin.