Column Toggler Laravel Package

Product Decisions This Supports

• Whether to expose table customization to internal operators at all. This package answers one narrow question: should support/ops/finance users be able to show or hide columns in Laravel Nova index tables themselves, or should engineering hardcode column sets per resource? It's a small add-on (47 stars, 0 dependents, MIT, v0.3.0 shipped 2025-01-28), so frame it as a cheap internal-UX convenience — not a table-configuration platform.

• Build vs. buy for admin table preferences. Concrete input for the "hand-roll or install?" call. Build cost is small in code but not zero in ownership: per-resource configuration, preference persistence, and Nova major-version churn all have to be owned either way. The buy side is inexpensive and reversible; the sell side is that you're now tracking a single-maintainer 0.x dependency in your admin stack.

• Nova 5 upgrade sequencing. v0.3.0 is a compatibility-only release — Nova 5 support contributed by a first-time contributor, nothing else listed. If column toggling is already in your workflow, this release unblocks or de-risks the Nova 5 migration and should be sequenced with the upgrade, not discovered mid-flight. On Nova 4, the package line splits: pin v0.2.x and treat 0.3.0 as gated on the upgrade.

• Closing a recurring, low-stakes feedback item. If "let me hide columns" keeps appearing in internal-tooling feedback, this closes it in an afternoon instead of permanently expanding your own surface area. That's a good use of budget — provided you accept the scope boundary below.

• A scope boundary worth writing down. Per-browser localStorage visibility is not saved views, per-role default column sets, shared filter presets, export, or server-side preference persistence. Treating this package as step one toward those distorts planning; they're a materially larger product problem needing separate funding.

• A dependency-risk register entry (low severity, real). Single maintainer, bursty cadence (v0.2.3 → v0.3.0), no stated automated test coverage against Nova 5, and a contradictory public description: the marketing copy calls it a Filament package while the code, changelog, and integration docs are all Nova. Blast radius is internal-only, so it belongs on the admin-stack watchlist rather than an unexamined composer require. Useful reminder that marketplace metadata for small community packages isn't authoritative — the repo's composer.json and changelog are.

When to Consider This Package

Adopt when:

• You run Laravel Nova and operators have asked for control over wide index tables — many columns, role-specific views, small screens.
• You are on, or moving to, Nova 5; v0.3.0 is the release that adds that support. Nova 4 environments should pin the v0.2.x line.
• The need is genuinely narrow ("toggle columns"), the surface is internal-only, and near-zero implementation effort outweighs vendor guarantees.
• Per-browser, per-resource localStorage preferences are an acceptable persistence model — i.e., you can tell users up front that preferences don't follow them across devices.
• You want the capability without owning per-resource UI code, and will assign a named internal owner plus a line on the Nova-upgrade checklist.

Look elsewhere (or build in-house) when:

• You are not on Nova. The description text claiming Filament support isn't backed by the changelog, code, or integration guidance — verify before assuming either way.
• Column visibility must be centrally governed (compliance, audit, field-level access rules) rather than left to individuals. Browser preferences are a convenience, not access control.
• You need saved views, per-role default column sets, export, or shared filter presets — different product, different budget.
• Procurement or security policy requires maintainer SLAs, security review, or demonstrated test coverage. Escalation path here is GitHub issues, with no such guarantees.
• Heavy index-view customization already exists — custom index components and other header-injecting tools are a known failure mode for the button rendering at all. Validate in staging before committing.
• The recurring maintenance tax of tracking a single-maintainer dependency exceeds the cost of a modest in-house toggle. Both sides of that comparison are small; make the call deliberately rather than by default.

How to Pitch It (Stakeholders)

To executives: This is a small, effectively free (MIT) Laravel Nova add-on that lets internal users hide and show columns in admin tables so operators can tailor dense data views to their own workflow. The decision-relevant update is v0.3.0, which adds Nova 5 support — so it won't become a blocker in our admin-panel upgrade path. Risk is contained: nothing customer-facing changes, preferences live in the user's own browser, and failure mode is degraded (operators fall back to full column sets) rather than blocked. The cost is one thin third-party dependency to track with a named owner, not a platform commitment. Recommend approving as a contained internal-tooling dependency with a pinned version and an explicit boundary that this is not the foundation for saved views or centrally managed column configuration.

To engineering: v0.3.0 is compatibility-only — Nova 5 support, first-time contributor, nothing else listed. Before adopting, answer two things the release notes don't: whether Nova 4 support was retained or dropped in 0.3.0, and what the exact nova constraint in composer.json says. If we adopt: pin the version explicitly (this is a 0.x line where a minor bump can carry a break), keep it out of customer-facing paths, register the tool in NovaServiceProvider::tools(), and validate the toggle renders alongside any custom index components we already use — including against filters, sorting, and pagination. Add it to the Nova-upgrade checklist so the next major bump triggers a dependency review instead of a post-deploy surprise. Plan the failure modes: preferences silently lost when localStorage clears or a column is renamed, and asset-build issues in the Nova pipeline. Fallback if we'd rather not carry a single-maintainer dependency for a UI convenience: a modest in-house implementation — small scope, equally small ongoing maintenance. Last note for any vendor evaluation: the package's public description incorrectly calls it a Filament package; treat the repo and changelog as source of truth.