Resized Column Laravel Package

Product Decisions This Supports

• Table UX investment in the admin surface. Filament powers a large share of Laravel back-office panels; the recurring complaint in data-dense tables is truncated or badly-proportioned columns. This package is a targeted, low-cost answer to that complaint, so it informs whether table ergonomics gets a slot on the roadmap at all.
• Build vs. buy (vs. borrow). Drag-to-resize on a Livewire/Alpine table header is deceptively fiddly — pointer events, min/max widths, interaction with Filament's own column configuration, and responsive breakpoints. Adopting a small, single-maintainer plugin is materially cheaper than a sprint of UI work; this package is the "borrow" option that must be priced against a two-day internal build.
• Scoping the personalization theme. Resizing is the shallow end of "let users shape their workspace." The decision this surfaces is whether column width is ephemeral convenience or the first slice of a persisted per-user layout (saved views, column visibility, filter presets). A plugin that only resizes client-side does not satisfy the deeper need — knowing which one you're buying prevents roadmap confusion later.
• Coexistence with the tools we already ship. v4.0.2 fixes a concrete stacking-context bug where a column-manager or filter trigger rendered as a ->modal() / ->slideOver() was trapped under the sticky thead and buried beneath Filament's topbar. That tells us the package is designed to sit alongside Filament's own table toolbar rather than replace it, which lowers the "conflict risk" line item in the build-vs-buy math — but only for setups that look like the one just patched.
• Where it earns its keep. Internal ops dashboards and back-office CRUD screens with 12+ columns and heterogeneous user workflows (finance scans amounts, support scans timestamps). Low value on narrow, consumer-facing or mobile-first tables.
• Risk allocation. A single maintainer and no dependents means this is a dependency you own, not a dependency you consume. v4.0.2 is a good sign — it is a real bug fix, not a chore release, and it landed quickly — but a patch that works by managing z-index against Filament's chrome is direct evidence the package reaches into Filament internals. That is a build-vs-buy input, not just a procurement footnote.

When to Consider This Package

Adopt when:

• You are already on Filament and the table pain is concrete — users asking for wider columns, horizontally scrolling to read one row, or exporting to spreadsheets to see data.
• You also use Filament's column manager or filters in the table toolbar. As of v4.0.2, modal and slide-over triggers from those tools correctly clear the sticky header, so the most common "these two things fight each other" scenario is now handled upstream. Pin at v4.0.2 or later rather than v4.0.1, which has the overlay-behind-topbar defect.
• The blast radius is acceptable: table headers only, no schema, no migrations, no data model change. It is revertible in one commit.
• You can pin the version and are willing to fork. Treat the code as vendored source you may need to patch — not as a supported product. The stacking-context fix is exactly the kind of change that can regress when Filament bumps its own z-index scale, so re-test on every Filament upgrade.
• You need a fast signal on demand. Shipping it internally for two weeks tells you more about appetite for table personalization than any survey.

Look elsewhere (or build) when:

• The license is unresolved. NOASSERTION is a hard stop for anything shipped in a commercial or redistributed product until legal reads it. This is the single biggest gate, and no patch release changes it.
• You need persisted, per-user column layouts or server-side saved views. Verify whether resizing survives a reload and a new session; if it's client-only, it does not meet that requirement.
• You are not on Filament — the package has no meaning outside it — or you are on a Filament major version the plugin has not declared support for. The v4.0.2 fix is tuned to a specific topbar and thead stacking order; a different Filament version can silently reintroduce it. Pin and test before committing.
• You already run a different table-customization plugin whose toolbar markup is not Filament's. The fix targets Filament's own .fi-ta-header-ctn container and toolbar modals; a third-party overlay may still collide.
• You require a vendor SLA, security review cadence, or a support contract. Single-maintainer projects cannot supply these.

How to Pitch It (Stakeholders)

For executives: This is a small UX win for internal tools, not a revenue feature. Our ops and back-office users work in dense tables all day, and fixed column widths are a persistent, low-grade friction — the kind that generates support tickets and quiet workarounds like CSV exports. This package lets users drag column widths themselves. v4.0.2 is a maintenance patch, not a feature release: it fixes a rendering bug where, if a team already uses Filament's column manager or filter panel in the table toolbar, that panel could open hidden behind the top navigation bar. That matters because it means the package plays nicely with the table tooling we already have rather than forcing a replacement. Cost is roughly an afternoon of integration plus a legal read of an ambiguous license; there is no infrastructure, migration, or ongoing hosting cost. The trade-off is dependency risk: one maintainer, few users, unclear license, and a fix that depends on Filament's internal styling. My recommendation is to adopt v4.0.2 or later behind a pinned version for internal-facing panels only, keep the diff small enough to revert, re-test whenever we upgrade Filament, and not let it into anything customer-facing or redistributed until legal signs off.

For engineering: One Composer dependency, one plugin registration in the panel provider, zero schema or data changes — behavior is confined to the table header. Pin to v4.0.2 at minimum; v4.0.1 has a known defect where a ->modal() / ->slideOver() column manager or filter trigger gets trapped inside the header's stacking context and renders beneath the topbar. Note what the fix actually does: the toolbar container gets z-index: 21 to clear the sticky thead, and is lifted above the chrome only while a toolbar modal is open. That is a deliberate coupling to Filament's stacking order (thead < 21, toolbar modal 40, topbar 30), so treat any Filament upgrade as a re-test trigger for table toolbar overlays specifically. Before merge I need three things: confirm compatibility with our Filament major version and that our column manager/filter config uses modal() or slideOver() where applicable; smoke-test opening each toolbar overlay with the plugin active to confirm nothing is clipped; and confirm whether width changes persist across sessions — if they don't, say so explicitly, because that changes what we can promise users. If the maintainer goes quiet, we fork and carry the patch, so keep the integration thin and avoid depending on internals beyond what we've already re-tested.