Filament Recurrence Laravel Package

Technical Evaluation

Architecture fit. This is a Filament panel plugin, which means it is a presentation-layer component, not a scheduling engine. The real architectural dependency is whatever RFC 5545 (RRULE) library sits underneath it — that library, not this package, determines correctness of recurrence expansion, DST behavior, and EXDATE/RDATE handling. Fit is strong when the application is already a Filament v3/v4 panel and the requirement is user-authored recurrence (an admin building a schedule through a form). Fit is weak when recurrence is machine-generated, when the UI is a custom frontend, or when the product only needs to read and expand rules — in that case the plugin's value (the UI) is unused and you are paying for a transitive dependency you don't need.

Integration feasibility. Mechanically low-friction: Composer install, register the plugin in the PanelProvider, publish config/assets, and persist the emitted rule string or JSON in a column you control. The package does not appear to dictate a schema, which is good for adoption and bad for portability — the storage contract is yours to define and yours to maintain. The realistic effort is not in wiring the plugin up; it is in deciding the persistence format, the timezone semantics, and whether occurrences are expanded at read time or materialized into rows.

Technical risk. Ranked:

Key questions for the vendor/spike.

1. Which underlying RRULE library is used, and what is its license and maintenance status?
2. What is the explicit Filament version matrix (v3 / v4), and is there a stated deprecation policy?
3. Does the package expose occurrence expansion as a service, or only the form component? If only the form, we own the expansion engine and should evaluate rlanvin/php-rrule or simshaun/recurr directly.
4. How are timezones represented — rule-local, UTC-normalized, or floating?
5. What is stored: a single RRULE string, a JSON blob, or structured columns? Is it stable across versions?
6. Test coverage, particularly around DST boundaries and month-end rules (31st of month, February).
7. Is there a documented upgrade path between minor versions, and a changelog?

Verdict. Reasonable adoption for a Filament-native product with moderate, UI-driven recurrence needs, provided the expansion engine is abstracted behind our own interface and the package is pinned. Not appropriate as the system of record for scheduling logic in a calendar-centric product without that abstraction.

Integration Approach

Stack fit. Laravel (10/11/12) + Filament + Livewire + Alpine + Tailwind, PHP 8.1+. This is the standard TALL-stack admin surface; assuming the product already runs Filament, there is no new runtime, no new build system, and no new hosting concern. If the product does not run Filament, the correct move is to evaluate the underlying recurrence library directly and skip this package entirely — do not introduce a panel framework to obtain a form field.

Migration path.

1. Spike (1–2 days). Install on a throwaway panel; validate the supported Filament version against ours; confirm the expansion API question above; build three rules by hand (weekly with exceptions, monthly by position, yearly with UNTIL) and expand them across a DST boundary.
2. Schema decision. Add a recurrence_rule (string, nullable) plus timezone (string) and, if needed, recurrence_ends_at. Store the raw rule, not a plugin-specific blob, so the persistence layer survives a package swap.
3. Backfill. Existing recurring records default to a single-occurrence rule or a rule derived from their current schedule fields; run as a one-off, idempotent migration with a dry-run mode.
4. Read path first. Implement occurrence expansion and any materialization job before exposing authoring UI, so the product behaves correctly against hand-written rules. This isolates the risky logic from the cosmetic change.
5. Write path. Wire the Filament field behind a feature flag on one entity type; measure before widening.

Compatibility. Confirm three version pins explicitly: Filament major, Livewire major, and PHP minor. Filament plugins commonly break on Livewire majors as much as on Filament majors. Check that the package's published assets are compatible with the panel's Tailwind strategy (Filament v3 ships compiled CSS; v4 moved toward Tailwind v4 conventions) — a mismatch shows up as an unstyled widget rather than an error, which is easy to miss in review.

Sequencing recommendation. Abstraction layer → read/expansion path → schema → UI → rollout. The temptation is to reverse the first two because the UI is the visible deliverable; resist it, because the UI is the cheap part and the expansion logic is where the defects live.

Operational Impact

Maintenance. Single-maintainer, 21-star, MIT-licensed project. Recent release activity is encouraging but does not offset concentration risk. The defensible posture is: pin the exact version, wrap the component and the expansion call behind an internal interface, and budget a fork if upstream goes quiet. MIT makes a fork legally trivial; the cost is the maintenance burden, not the license.

Support. Community-only. There is no SLA, no commercial backstop, and issue response times are unpredictable at this scale. Any production dependency on it should have an identified internal owner who can read the underlying RRULE library's source when something breaks.

Scaling. Two distinct profiles:

• Write path is trivially scalable — a form field, one row per rule.
• Read path is the concern. Expanding rules on every request is CPU-bound and degrades in proportion to the date range and the number of rules. For anything beyond low-volume dashboards, materialize occurrences into an indexed table via a scheduled job, with a bounded horizon (e.g., rolling 90 days) and a guard on unbounded rules. Index on (entity_id, occurs_at).

Also scope any query that counts or lists "upcoming" items — a naive WHERE on a rule string is not queryable and will force full-table expansion.

Failure modes to design against.

• Unbounded rules. A rule with neither COUNT nor UNTIL will expand indefinitely. Enforce a horizon at the expansion boundary, not in the UI.
• DST drift. A 09:00 local rule across a transition can render as 08:00 or 10:00 if timezone handling is inconsistent between storage and display. Test explicitly; this is the most common recurrence bug in production.
• Month-end semantics. 31st rules silently skip short months depending on library behavior. Confirm and document the expected behavior with stakeholders — this is a product decision, not a bug.
• Panel upgrade breakage. A Filament major upgrade will likely require a plugin version bump in lockstep. Treat the two as a coupled upgrade unit in planning.
• Asset pipeline omission. New plugin assets not published in the deploy step → broken UI in staging/prod but fine locally.
• Schema lock-in discovered late. If the stored format is opaque, an engine swap becomes a migration project. Mitigated by step 2 above.

Ramp-up. Low for any developer already fluent in Filament — the component is conventional and the API surface is small. The genuine learning cost is domain knowledge: RFC 5545 semantics, timezone rules, and exception handling. Plan for that as a product competency (shared with whoever owns scheduling UX), not a package-specific one; it transfers if the package is later replaced. Expect roughly a day for a Filament-fluent engineer to be productive with the component, and considerably longer to be confident in the expansion behavior.