Calendar Laravel Package

Product Decisions This Supports

• Build vs. buy on the calendar surface itself. The decision a PM actually faces here is not "which calendar library" but "do we staff a front-end build for a calendar view in our admin panel." For a Filament-based panel, this package collapses that into PHP configuration: month/week/day/list views, drag-drop-and-resize with persistence, and create/edit through existing Filament actions. The saved engineering time should be redirected to the scheduling logic that differentiates the product — availability rules, conflict resolution, booking state machines — none of which ship here.
• Roadmap sequencing for time-based features. Appointment scheduling, shift planning, resource calendars, and team-availability views all reach the presentation layer through this package. The 3.2.x line reads as additive and stabilizing (3.2.2 is five targeted fixes plus two chores, no breaking changes), so these roadmap items don't need a rewrite-risk buffer in their estimates.
• Contextual actions as a spec item, not a stretch goal. The 3.2.2 release makes "right-click an event → Reschedule / Reassign / Cancel" a first-class pattern: mounted actions receive their context payload, the menu only opens once actions resolve, and lookups are scoped to the owning widget. Product can now spec per-event-type actions instead of forcing a record-detail round trip — a measurable click reduction in high-frequency admin workflows. Keep the action list to three-to-five items; anything needing a form goes in a modal, not a full page.
• Multi-calendar dashboard layouts. Scoping context-menu lookups per widget makes "my calendar + team calendar on one screen," each with its own event source, actions, and authorization, a layout decision rather than a custom build. This is the pattern the 3.2.2 fix was written for.
• Navigation UX as a default choice. Destroy-on-unmount means wire:navigate transitions no longer duplicate calendar widgets. Choosing SPA-style navigation for the admin panel becomes safe rather than an engineering negotiation — a cheap perceived-performance win.
• Self-hosting as a compliance posture. 3.2.2 bundles @event-calendar/core from npm instead of loading it from a CDN. That removes a third-party runtime fetch: fewer CSP allowlist entries, no CDN outage exposure on scheduling pages, no unapproved upstream drift. It makes this viable in air-gapped or data-residency-constrained deployments where a CDN-dependent alternative would be disqualified at procurement.
• A scoping guardrail to invoke early. The package description leans on "FullCalendar" and mentions recurring events, which will set stakeholder expectations higher than reality. The underlying engine is vkurko/calendar/@event-calendar/core, and recurrence expansion with exceptions, availability rules, conflict detection, and timezone-correct booking are all out of scope. Use the package to bound the conversation — never to imply a scheduling engine comes free.

When to Consider This Package

Adopt when:

• You are already on Filament, and the calendar is an admin-panel or internal-tooling surface. Nearly all the value is stack fit; without Filament you'd wrap the JS library yourself.
• You need display plus lightweight interaction — view switching, click-through to records, contextual actions — not a scheduling engine.
• Self-hosted assets are required (air-gapped, strict CSP, data residency, regulated deployment).
• Your team has more Laravel/PHP capacity than JS capacity and prefers configuration over a bespoke front-end build.
• You need multiple independent calendars on one screen with per-widget actions and authorization.

Look elsewhere when:

• You need real-time collaborative scheduling, conflict detection, recurrence with exceptions, or timezone-heavy booking. You will build and own all of it.
• Your front end is not Filament — Inertia/Vue/React, or a public-facing site. The Filament integration is the product.
• You need resource-timeline or Gantt-grade capacity planning, or grid customization beyond what @event-calendar/core exposes.
• The calendar is load-bearing for revenue and maintenance-risk tolerance is low: 315 stars, zero declared dependents, single-maintainer footprint, no commercial backing or SLA.
• You require vendor SLAs or contractual support.

Two caveats to hand engineering before committing:

1. 3.2.2 is a patch that changes asset delivery. Anyone who pinned a CDN version, customized asset loading, or added a CSP exception must re-verify the whole build pipeline. Failure mode is a silently blank calendar container — no obvious console error.
2. Pin the Filament constraint explicitly. The supported range isn't loudly documented, and the package tracks Filament majors actively. A composer update that silently crosses a Filament major is a bad afternoon.

How to Pitch It (Stakeholders)

To executives: We can ship calendar surfaces — appointments, shifts, team schedules — into our Filament admin panel without a front-end project. The package covers rendering, view switching, drag-and-drop rescheduling with automatic persistence, and right-click contextual actions, all configured in PHP by the team we already have. It's MIT-licensed and self-hosted, so there's no vendor contract, no CDN dependency, and no procurement review for third-party runtime calls. What it does not include is the scheduling engine — recurrence rules, conflict detection, timezone handling — so any "booking system" ask must be scoped and estimated separately. Treat this as the display layer and budget the logic behind it honestly.

To engineering: It's a thin, well-scoped Filament wrapper over @event-calendar/core. Idiomatic usage is one widget class per calendar surface, composed onto dashboards or resource pages, with a dedicated range-bounded event-source method and Filament Actions as context-menu items. Re-resolve and re-authorize every record from the context payload — never trust it as the source of truth. Start from the workbench/ panel added in 3.2.2 rather than the README; it's the maintainer's actively exercised reference implementation. Debug in one layer at a time: PHP event source → JS asset loaded → single Livewire mount → action resolution.

The honest risk statement: small ecosystem (315 stars, zero declared dependents, single maintainer). That's fine for internal admin surfaces where a fallback is "rebuild the view." It is not fine as the foundation of a customer-facing revenue flow. Watch release cadence over a couple of months before committing a roadmap to it, and keep the escape hatch cheap by isolating the event-source logic behind our own interface rather than scattering it through widget classes.