mokhosh/filament-kanban
A Kanban board package for Filament and Laravel. Turn any Eloquent model into a drag-and-drop Kanban board with sortable columns and cards, status transitions, and a clean, customizable UI that integrates seamlessly into your Filament admin panels.
mokhosh/filament-kanban is a UI package for Filament (the Laravel admin panel framework) that renders Kanban-style board views. v2.11.0 is a maintenance release: two Dependabot bumps limited to CI workflows (dependabot/fetch-metadata, stefanzweifel/git-auto-commit-action), one bug fix (Fix issue #81), and a method-signature correction by a first-time contributor. No new features, no deprecations, and no public API surface was added. The signature fix is the only item warranting a compatibility glance — in Filament plugin packages these are typically aligning overrides with upstream parent class signatures (LSP/PHP 8.x compliance), which is a correctness fix rather than a BC break for consumers, but it should be verified against our Filament version since mismatched signatures are exactly what causes runtime Fatal error on class load.
Architecture fit: Strong if we are already on Filament. The package is a presentation-layer component, not an infrastructure dependency — it does not own data, persistence, or queue semantics. Board state is typically persisted via a model on our side, which keeps the coupling shallow and exit cost low.
Integration feasibility: Low effort for a Filament-native team. Requires publishing/registering a plugin provider, wiring a model that exposes the required ordering/status contract, and styling. Most effort is in the data contract, not the package.
Technical risk: Low-to-moderate overall. The main risks are (a) version-lock to a specific Filament major, since Filament itself has shipped breaking majors recently; (b) bus-factor — this is a small, single-maintainer package where v2.11.0 is the first release with two new outside contributors, which is a positive signal for community health but still a thin contributor base; (c) the method-signature fix implies the package tracks upstream Filament internals closely, so Filament upgrades will likely require a coordinated package bump.
Key questions: Which Filament major does v2.11.0 pin, and does it match ours? What was issue #81, and does it affect our use case? Is the signature fix backward compatible for consumers who extended or overrode the affected methods? Does the package declare a supported-PHP matrix, and are we inside it?
Stack fit: Native. Assumes Laravel + Filament + Livewire. If our admin surface is Filament-based, this slots in as a plugin with no adapter layer. If we are not on Filament, the package is not usable — do not attempt to extract its board logic for a bespoke UI.
Migration path: Greenfield or additive only. Introducing a Kanban board is a new view over existing records; it should not require schema migration if our model already has an ordering column and a status/enum field. If those are absent, budget a migration and a backfill for ordering.
Compatibility: Pin Filament and this package together in composer.json and treat them as a coupled pair. Given the signature fix in this release, do not adopt v2.11.0 on a Filament version materially newer or older than the one the maintainer targets — validate by loading the board page in a staging environment before merging.
Sequencing: (1) Confirm Filament and PHP versions match. (2) Install the previous release (v2.10.0) if we are mid-sprint to avoid conflating the bug fix with onboarding issues, or go straight to v2.11.0 if greenfield — the delta is small. (3) Register the plugin and render a read-only board against a non-critical model. (4) Add drag/status-change mutation once persistence is verified. (5) Then expose to end users.
Maintenance: Near-zero ongoing maintenance from us — no database, no background jobs, no config drift. The cost is upgrade coordination: each Filament major bump will likely require waiting on a corresponding kanban release. Budget a small recurring line item for that coupling rather than assuming it is fire-and-forget.
Support: Support burden shifts to the UI team, not platform. Users will report drag-and-drop and ordering behavior; debugging means reading Livewire component state, so the on-call rotation should include someone fluent in Filament/Livewire, not just Laravel.
Scaling: Board rendering cost scales with the number of cards on a single board. Large boards (hundreds to low thousands of cards) can produce slow Livewire payloads and sluggish drag interactions. Plan to paginate or filter by column/assignee before scaling to large datasets; do not assume the package handles virtualization.
Failure modes: (a) Silent breakage on Filament upgrade due to signature drift — mitigated by pinning and a smoke test on the board route in CI. (b) Maintainer abandonment — mitigated by the shallow coupling; worst case we fork or replace the view layer while keeping the data model intact. (c) Ordering corruption from concurrent drag operations — needs a server-side ordering strategy (transaction or sequence) rather than trusting the client. (d) Missing/renamed config or view publish after an upgrade.
Ramp-up: Half a day for a Filament-experienced developer to install, wire a model, and render a working board. One to two days to add mutations, ordering safety, and tests. Non-Filament developers should not be assigned this — the learning curve is Filament and Livewire, not the package itself.
Release verdict for v2.11.0: Adopt, low urgency. It is a bug-fix and hygiene release with no feature or deprecation surface; the only action item is verifying the method-signature fix against our pinned Filament version during the normal upgrade cycle.
How can I help you explore Laravel packages today?