Calendar Laravel Package

Technical Evaluation

Architecture fit. The package is a Filament plugin that renders @event-calendar/core (vkurko) as a Livewire widget, configured entirely in PHP: view types, event sources, context-menu actions — one widget class per calendar surface. It is strictly a presentation layer. Everything that makes scheduling hard — recurrence expansion with exceptions, availability rules, conflict detection, timezone-correct booking, write-side concurrency — stays in our codebase. Fit is therefore binary: high if the target surface is an internal admin panel already on Filament, near-zero otherwise (the Filament integration is the product; without it you would wrap the JS library directly). The workbench/ Filament panel added in 3.2.2 is the reference implementation, and it is more trustworthy than the README.

Integration feasibility. Small public surface: plugin registration, widget class, view-type enum, event-source method, action list. First render is roughly half a day for a Laravel developer; a production read-only month view with authorization is 1–2 days; the interactive pattern (drag/resize persistence + context-menu actions) is about a week including tests. The one hard prerequisite is a working asset pipeline — the calendar JS is bundled from npm as of 3.2.2 and must flow through npm run build and our CSP. That is infrastructure work, not package work, and it should be proven in a spike before any estimate is committed.

Technical risk.

• Ecosystem risk (highest). 315 stars, zero declared dependents, single-maintainer footprint, no commercial backing, no SLA, MIT. Zero dependents is a thin signal — it does not mean bad code, it means few people have stress-tested upgrade paths before us.
• Filament major-version coupling. The package tracks Filament actively but the supported range is not loudly documented. A ^ constraint that silently crosses a Filament major is a credible outage.
• Patch-level operational change. 3.2.2 moved asset delivery from CDN to npm-bundled inside a patch release. Correct call, but it means semver is not a reliable proxy for operational impact here. Anyone with a CDN CSP allowlist or custom asset loading gets a silently blank calendar.
• Behavioral change disguised as a fix. Context-menu lookups are now scoped to the owning widget. For multi-calendar pages, code that "worked by accident" under ≤3.2.1 may behave differently after upgrade.
• Scope inflation. Stakeholders hearing "calendar" will assume a booking engine. Recurrence, conflicts, and timezones are explicitly ours to build and own.
• Trust boundary. Context payloads cross a Livewire round trip; they are request parameters, not sources of truth.

Key questions to put to engineering, security, and product before committing budget.

1. Which Filament major are we on, and what does the package's composer constraint actually permit? Will we pin explicitly?
2. Does our Vite/CI pipeline pick up npm-bundled package assets, and what CSP changes are required?
3. Is the surface internal admin or customer-facing / revenue-bearing? (This decides whether the maintenance posture is acceptable.)
4. Do we need recurrence, conflict detection, or timezone-heavy booking? If yes, who owns that build and what is its separate estimate?
5. Do we need two calendars on one screen with independent actions and per-widget authorization?
6. Are there air-gap / data-residency / CSP constraints? (Bundled assets are a genuine qualifier here.)
7. Who is the named internal owner, and is a soft fork acceptable if upstream stalls?

Integration Approach

Stack fit. Laravel + Filament + Livewire + Blade, events as Carbon instances, no JS framework commitment. Ideal when the team has more PHP capacity than front-end capacity and prefers configuration over a bespoke build. Directly supports resource scheduling, shift planning, appointment lists, and team-calendar views as admin views.

Migration path. Greenfield — no data migration, no API contract. composer require → register the plugin in the panel provider → rebuild assets → add a widget class → map one Eloquent model to events. Existing bespoke FullCalendar pages, if any, can be retired surface-by-surface: stand the new widget up beside the old page, validate, then cut over. Each calendar surface is independently shippable, which keeps blast radius small.

Compatibility checklist (gate before merge).

• Pin the Filament constraint explicitly; do not let ^ resolve across majors.
• Confirm PHP, Laravel, and Livewire versions against the package's composer requirements.
• If on an older 3.2.x, verify the view-type enum is complete (it was fixed in 3.2.2).
• Confirm the built asset is served and permitted by CSP in the target environment.
• Confirm no wire:ignore workarounds exist from prior calendar attempts — they reintroduce the duplicate-mount leak that 3.2.2 fixed.

Sequencing.

1. Spike (1–2 days). Run the workbench panel, render a read-only month view over one model, and prove asset delivery in our pipeline with our CSP. Two distinct failure domains — PHP config vs. asset delivery — and the spike must close both.
2. Read path. A dedicated event-source class taking a date range and returning events (id, title, start, end, optional color/url). One widget class per calendar surface; per-widget canView() authorization falls out for free. Resist context menus until this is solid — a bad event source and a broken context menu look identical from the browser.
3. Interaction. Three to five Filament actions per menu, each re-resolving the record through Eloquent and re-authorizing before acting. Anything needing a form becomes a modal action, not a page round trip.
4. Multi-calendar layouts and SPA navigation. Safe post-3.2.2; treat as a layout decision rather than engineering work. Give each instance a distinguishable key.
5. Deferred, separately estimated. Recurrence expansion, conflict detection, timezone booking. Do not let these hide inside the calendar ticket.

Extension guardrail. Extension order is custom event arrays → custom actions → Blade wrappers → custom view types → stop. If requirements need grid rendering beyond what @event-calendar/core exposes, that is a signal to reconsider the dependency, not to fork the JS.

Operational Impact

Maintenance. The package itself is small; our real recurring burden is three things: Filament upgrades, the asset pipeline, and the scheduling logic we own. Budget a compatibility review at every Filament major and a read of release notes at every bump — 3.2.2 proves patch releases can carry operational impact. 3.2.x overall is additive and stabilizing (3.2.2 is five targeted fixes plus two chores, no breaking changes), which means roadmap estimates for time-based features do not need a rewrite-risk buffer.

Support. MIT, community only, no vendor SLA, no paid support. Acceptable for internal admin surfaces; think hard before making it the foundation of a customer-facing revenue flow. Mitigations: name an internal owner, track upstream releases deliberately (no blind autobump), and keep a fork-ready posture — the public surface is small enough that a soft fork is a contained cost if upstream stalls. Watch release cadence over a couple of months before committing the roadmap to it.

Scaling. Cost is per-page and per-widget. Event sources must be range-bounded or month views over large tables will degrade — inline the query into the widget and you re-derive range logic on every new view or source. Watch for N+1 in the event source. Multiple calendars on one page multiply queries and Livewire round trips; keep action lists short and action-resolution fast, because 3.2.2 only opens the context menu after actions resolve — slow resolution presents to the user as a broken right-click. This is not a real-time system: no websockets, no collaborative editing, no presence. Drag/resize persistence is effectively last-write-wins unless we add version checks or optimistic locking server-side.

Failure modes and the detection order that works.

• Blank calendar container → asset bundle didn't load. Check the network tab for the calendar asset, not the console; post-3.2.2 also check CSP. No obvious error is thrown.
• Duplicated widgets → Livewire component mounted twice. Inspect DOM for duplicate containers; do not add wire:ignore.
• Right-click does nothing → most likely an exception in our action-resolution code. Check storage/logs before the browser.
• Empty or wrong events → range-bounded event source; log the PHP array for the visible range.
• Action firing on the wrong calendar → per-widget scoping; verify on any upgrade from ≤3.2.1 with multiple calendars.
• Silent Filament major bump → prevented by pinning, not by detection.

Cheap instrumentation worth building once: a staging log of event-source output per range, plus a smoke test asserting the calendar asset is served and exactly one widget container mounts. Those two tests cover both silent failure modes.

Ramp-up. Low. The public surface is small and the workbench panel is effectively the documentation. Expect half a day to first render, 1–2 days to a production read-only view with authorization, about a week to the interactive pattern with tests. Two organizational notes: keep a short internal note documenting our wiring so it isn't relearned at every Filament upgrade, and ensure a second reviewer understands the pattern — single-owner knowledge concentration on a single-maintainer dependency is a compounding risk.