Column Toggler Laravel Package

Technical Evaluation

• Architecture fit: dcasia/column-toggler is a single-purpose Laravel Nova tool that injects a runtime show/hide control into resource index views. It carries no domain logic, no API surface, no persistence layer of its own, and no customer-facing behavior — which makes the fit decision binary rather than graduated. It applies only if the stack runs Nova and operators have an articulated pain point with wide, role-fragmented index tables. If either condition is false, it is noise in the dependency graph. Frame it to stakeholders as an admin-UX lever, not a platform capability.

• Integration feasibility: Low effort, tightly bounded. Composer install, registration in NovaServiceProvider::tools(), optional config/view publishing. Measured in hours, not sprints. The TPM's contribution is scoping, verification, and named ownership — not the code path.

• Technical risk: Moderate but contained. The dominant long-term risk is structural: the package hooks Nova's frontend table internals, so it is inherently sensitive to Nova major-version churn. Secondary risks: single-maintainer concentration (v0.3.0 was contributed by a first-time contributor and contains nothing but Nova 5 support); no stated automated test coverage against Nova 5; a 0.x semver line where a minor bump can legitimately carry breaks (0.2.3 → 0.3.0); and a contradictory public description — the marketing copy calls it a Filament package while the repo, changelog, composer constraints, and integration guidance are all Nova. Metadata is not authoritative here; composer.json and the changelog are.

• Key questions to force answers to before commitment:

  • What operator problem does this solve, and how was it validated — support tickets, UX review, recurring table-width complaints?
  • Are we on Nova 5 today, or is this bundled into an upgrade program? What is that timeline?
  • Does v0.3.0 retain Nova 4 support or drop it? What does the nova constraint in composer.json actually say?
  • What is the honest build-vs-buy delta — hours to build a minimal in-house toggle versus the recurring cost of tracking a single-maintainer dependency?
  • Do column preferences need central governance (compliance, audit, role defaults)? The localStorage model cannot satisfy that, now or later.
  • Who is the internal owner, and what is the exit plan if upstream goes stale?

Integration Approach

• Stack fit: Restrict to Laravel applications on Nova 5; confirm PHP/Laravel versions against Nova 5 requirements. Do not generalize this into a "table configuration" story — it is not a Filament plugin and not a general Laravel table solution, despite the description text. Correct any planning document that frames it otherwise.

• Migration path: Two tracks depending on current state. Already on Nova 5: bump 0.2.3 → 0.3.0 on a branch and validate toggling on the highest-traffic resources. On Nova 4: pin 0.2.x and gate the 0.3.0 bump on the Nova 5 upgrade — do not assume one constraint spans both versions. Where the package is not yet adopted, sequence it as a small rider on the Nova 5 upgrade, not a standalone initiative.

• Compatibility: Verify in staging, not by reading release notes. Specifically: the Nova constraint in composer.json, whether Nova 4 support survived 0.3.0, asset compilation behavior in the Nova build pipeline, and interaction with any custom index components — the toggler renders into the standard Nova header slot, a known collision point where the control can fail to render at all. Test toggling alongside filters, sorting, and pagination.

• Sequencing:

  1. Confirm the operator need and define success criteria (e.g., measurable decline in "too many columns" requests).
  2. Decide build vs. buy with a real number: hours for a minimal in-house toggle vs. carrying the dependency.
  3. Lock the Nova version target and validate the matching package line.
  4. Staging rollout on 2–3 representative resources, including one with heavy customization.
  5. Internal cohort pilot with a named owner collecting feedback.
  6. Broad enablement with a documented reset path (clear site data / incognito) for users stuck on stale localStorage preferences.

• Scope discipline: Explicitly out of scope unless separately funded — saved views, per-role default column sets, export, shared filter presets, server-side preference persistence. Those are a materially larger product problem; treating this package as step one toward them will distort the roadmap and set false expectations with stakeholders.

Operational Impact

• Maintenance: Low code footprint, high dependency-attention requirement. The work is not patching the package — it is monitoring releases around Nova majors, pinning versions explicitly, and re-validating on each upgrade. Assign to the team that owns Nova frontend dependencies and budget a recurring slice per Nova upgrade cycle, not a one-time install.

• Support: No vendor SLA; GitHub issues are the escalation path. Acceptable for an internal admin surface, not for regulated or customer-facing workflows. Set expectations with operators up front: if toggling breaks, they fall back to full column sets — degraded, not blocked.

• Scaling: Negligible backend load; preferences are per-browser, per-resource localStorage. The real scaling questions are UX-scaling: very wide tables, many resources, and users expecting preferences to follow them across devices. That expectation is a product gap this package will not close — state it during rollout to avoid a follow-on request cycle.

• Failure modes to plan for: Nova major upgrade breaks the Vue component; asset build failures in the Nova pipeline; Composer constraint conflicts during upgrade; silent preference loss when localStorage is cleared or a column is renamed; conflicts with other tools modifying the index header. Mixing package lines across Nova versions is the highest-probability failure and should be caught by explicit pinning plus a staging check. Add the package to the Nova-upgrade checklist as a named dependency so future major bumps trigger a review rather than a post-deploy surprise.

• Ramp-up: Developers need almost none — registration plus optional config. The ramp-up cost sits with product and QA: deciding which columns are toggleable per resource, whether defaults are sensible per role, how the reset path is communicated, and how to adjudicate conflicts between multiple header-injecting tools on the same index view. Plan a short enablement note for operators explaining the per-browser persistence model, since that is the expectation most likely to generate a follow-up ticket.