Filament Visual Cron Builder Laravel Package

Technical Evaluation

Architecture fit. The package respects Filament's field extension model rather than fighting it: CronBuilder is a form field that owns a single string state path, so it substitutes 1:1 for a TextInput bound to a cron column. That means zero schema change, zero data migration, and a trivially reversible swap. The more strategically useful artifact is CronExpressionBuilder (compose/parse/humanReadable) plus the ValidCronExpression rule — these are framework-level utilities usable outside the form layer, e.g. validating stored schedules in a console command, an API payload, or a seeder, and for backfilling human-readable labels into read-only tables. Treat the field as the UX layer and the builder/rule as the durable contract.

Integration feasibility. High for greenfield Filament v4 panels; effectively zero for Filament v3 estates, since no backport or compatibility shim is advertised. The dependency surface appears small (a cron parsing library and Filament itself), and if it leans on the cron-expression parser already transitively present via illuminate/console, the added weight is near nil. The "drop-in for TextInput" claim is the single most important line in the notes and should be verified by diffing the field's state/validation behaviour against the incumbent before rollout.

Technical risk.

• Maturity: v1.0.0, single release, no stated test suite, CI, license, or PHP/Laravel/Filament version matrix. Bus factor is likely 1.
• Timezone and DST correctness: "next-run" is meaningless without a declared timezone. If the preview computes in UTC or server-local while the scheduler runs in config('app.timezone'), administrators will trust a wrong preview — the highest-severity failure mode here, and a silent one.
• Dialect ambiguity: five columns implies standard cron. Non-standard syntax (L, W, #, ?, Quartz 6/7-field, AWS EventBridge) handling is unspecified.
• Round-trip fidelity: whether parse() → compose() preserves the operator form the user chose (*/5 vs 0,5,10,…) affects diff noise and user trust in the editor.
• UI surface: a 5×4 control grid plus live preview carries accessibility (keyboard nav, screen readers) and bundle-size implications; no accessibility statement is provided.
• Failure degradation: unclear whether the field falls back to a raw text input if the JS asset fails to load. A field that blocks form submission on asset error is an operational hazard for an admin panel.

Key questions.

1. Maintainer identity, license, and stated support window — and is there a funded path to Filament v5?
2. Which timezone drives "next-run", and is it configurable per field? How are DST gaps/overlaps rendered?
3. Does the package delegate parsing to dragonmantank/cron-expression (or equivalent), or hand-roll it?
4. Test coverage and CI matrix — which PHP/Laravel/Filament versions are actually exercised?
5. Is parse()/compose() lossless for operator-style expressions, and what happens on unparseable legacy values already in the column?
6. Is there a no-JS/text fallback, and is there an accessible-label story for the column controls?
7. Is humanReadable() localized, or English-only?

Integration Approach

Stack fit. Laravel 11/12 + Livewire 3 + Filament v4 panels. Any application still on Filament v3, or planning a v3→v4 migration beyond the current quarter, should defer adoption until the panel upgrade lands — do not let a cosmetic field become the reason a panel migration is sequenced early.

Migration path. Low-risk and reversible: replace the TextInput::make('cron') (or equivalent) with CronBuilder::make('cron'), keeping the same name, label, and any existing ->rules([...]); add ValidCronExpression to the rule set if the incumbent lacked server-side validation. No database change. Rollback is a single class swap. Pre-existing column values must be smoke-tested — hand-written or legacy expressions are the realistic source of parse failures.

Compatibility. Pin the exact version ("vendor/package": "1.0.0"), not a caret range, while the package is pre-1.x-stable in practice. Audit composer.lock for duplicate or conflicting cron-expression parsers before and after install. Confirm the published assets are versioned and included in your deployment build step — Filament asset publishing is a common silent-breakage point in CI pipelines that cache public/.

Sequencing.

1. Spike (0.5 day). Install in a branch, render the field, and compare the generated string against the incumbent for 10–15 representative schedules.
2. Correctness gate. For each generated expression, cross-check the package's human-readable and next-run output against Laravel's own scheduler resolution and an independent parser. Only proceed if they agree, including across a DST boundary.
3. Pilot. One low-traffic admin resource, one release cycle, with the old TextInput shippable behind a feature flag.
4. Broaden. Roll out to all cron-bearing resources once the pilot surfaces no divergence; add a console command or test that asserts every stored cron value passes ValidCronExpression and parses cleanly.
5. Contingency. Keep a thin internal wrapper around the field so the package can be forked or swapped without touching resource classes.

Operational Impact

Maintenance. The dominant cost is ownership risk, not code. A v1.0.0 with an unstated support model will need an internal owner who can read the field's JS and patch it, or an accepted plan to fork. Filament's major-version cadence is the forcing function: assume a v5 field-API break and budget a maintenance window for it. Track upstream releases on a schedule rather than reactively.

Support. No commercial support or SLA is implied. Escalation is GitHub issues against a bus-factor-1 project; plan for self-resolution and keep the internal wrapper as the isolation boundary so a stalled upstream doesn't strand the panel.

Scaling. Negligible runtime impact — the field only exists on admin form renders, and the utilities are cheap. The one thing to watch is preview recomputation: if the human-readable/next-run preview round-trips to the server on every keystroke via Livewire, form interaction becomes chatty for admins on high-latency links. Confirm whether preview is client-side or server-debounced; if server-side, ensure it is debounced and does not fire on every option toggle.

Failure modes.

• Wrong next-run preview (timezone or DST mismatch) — highest severity because it is silent and erodes trust in the whole scheduling UI. Mitigate with a documented, single source of truth for timezone and a test that pins it.
• Stored expression never fires (e.g. an impossible day-of-month/month pairing that the UI permits but the scheduler will skip) — mitigate with a validation layer that checks the next few run times resolve, not just syntactic validity.
• Unparseable legacy value on edit — the field must degrade to showing the raw string rather than throwing or silently blanking, otherwise editing an old record destroys the schedule.
• Silent input rewriting (*/5 normalized to an enumerated list) — produces confusing diffs and makes admins distrust the saved value.
• Asset load failure in the admin panel blocks form submission — verify the text fallback before pilot.
• Lockfile drift introducing a second cron parser — pin and audit.

Ramp-up. Low for anyone already fluent in Filament fields: the API is idiomatic and the mental model (one string state path, one validation rule) is familiar, so integration is roughly half a day plus the correctness gate. The real ramp-up cost sits with whoever on the team must own cron semantics — timezone, DST, dialect edge cases — because that person, not the package, is the actual guarantor that the schedules administrators build will fire when they expect. Budget a short internal note documenting the supported dialect and timezone contract alongside the integration.