Timex Laravel Package

Technical Evaluation

Architecture fit. Unchanged. buildix/timex is a Filament plugin that adds calendar rendering to a Laravel admin panel: a service provider, a Filament plugin contract implementation registered on a PanelProvider, and a Livewire component/Blade view wrapping a client-side calendar library. Fit remains high if and only if the target application already standardizes on Filament as its admin layer. It is a presentation-layer package — no event model, no scheduling engine, no iCal ingestion — so it is a UI accelerator, not infrastructure. Teams not on Filament get zero value.

Integration feasibility. Low mechanical effort, high verification effort — but release 1.1.7 materially moves the first gate. The single line item, "Fix Laravel 10 composer require," tells us the previous release failed dependency resolution on Laravel 10 and that this has been corrected. That eliminates the cheapest and most common failure mode: a composer install that refuses to resolve. Practically, this means the Phase 0 spike will now likely install on a Laravel 10 application rather than aborting at the solver.

That is a genuine improvement, but it is a narrow one, and it shifts the risk rather than retiring it. A composer constraint fix says nothing about Filament's plugin contract, Livewire's component lifecycle, or the asset pipeline. The more dangerous outcome is now the likelier one: a clean install followed by a panel that fails to boot or renders an empty page. A solver error is a five-minute answer; a runtime contract mismatch in a registered Filament plugin is a debugging session against an unfamiliar and stale codebase. Verification effort does not drop — it relocates.

Note also what the release note implies rather than states: someone hit this problem in a real Laravel 10 application, which is mild evidence of at least one consumer attempting a modern install. One data point is not a dependent base, but it is better than the silence the previous assessment described.

Technical risk.

• Framework drift (high, partially re-scoped). The Laravel dimension of the drift is now addressed up to the 10 line; the Filament and Livewire dimensions are not. Filament's plugin contract, panel registration API, and asset pipeline changed materially across v2 → v3 → v4, and a composer constraint fix on Laravel says nothing about any of them. Failure mode remains a panel that fails to boot — whole-application admin outage, not a degraded widget.
• Maintenance signal (high, marginally improved). Single-org package, now two releases in the observable window, still zero dependents on Packagist. The cadence is no longer "one release ever," which is a real if small positive: the maintainer is reachable and responsive to install failures. But responsiveness to a composer constraint is not the same as an active compatibility program, and zero dependents still means no community canary and no de facto regression suite against modern dependency sets.
• Transparency gap (medium). Unknown test coverage, unknown transitive JS dependency, no published security policy, and — critically — no published compatibility matrix naming the supported Filament and Livewire majors. Release 1.1.7 does not close this; it is the kind of gap that gets closed by a README table, not a patch release.
• Scope ambiguity (medium). Unchanged. "Calendar plugin" could mean read-only display, full CRUD against Eloquent models, or external sync — wildly different integration costs.

Key questions — updated for 1.1.7.

1. Does it install on Laravel 10? Largely answered: yes. The remaining question is the Filament major: does composer.json now constrain Filament 3.x/4.x, or only 2.x? This is now the single decisive question.
2. Does the panel actually boot and render with the plugin registered on our current Filament version? (Replaces the install question as the spike's purpose.)
3. Is the calendar read-only, or does it bind to a model with create/update/drag-to-reschedule? Where does persistence live?
4. Which client-side calendar library is vendored or required, at what version, and what is its license?
5. Has asset registration been ported from Laravel Mix to Filament's Vite-based publishing?
6. Timezone and DST handling — server-side timezone config, per-user timezone, all-day event semantics?
7. Recurrence support, or flat single-instance events only?
8. Localization/i18n coverage for our target locales?
9. Is there a test suite, and does CI run against a modern Filament matrix?
10. Responsive/accessibility story for the calendar grid?

The 127-star count still indicates the package is findable rather than good. The 1.1.7 release upgrades the package from "cannot install on our stack" to "can install on our stack, unproven beyond that." Treat both as discovery signals.

Integration Approach

Stack fit. Target assumption unchanged: Laravel 10/11, PHP 8.1+, Filament 3.x or 4.x, Livewire 3, Tailwind 3/4, Vite. Release 1.1.7 narrows the gap at one layer — the Laravel 10 composer constraint now resolves, so the package plausibly installs on Laravel 10 — but the Filament 2.x, Livewire 2.x, and Mix-era asset assumptions remain unaddressed and unverified. The gap is now "one framework generation at the Filament/Livewire layer" rather than "one to two generations across the board." Smaller, not closed.

Migration path — three credible options, preference order unchanged.

1. Substitute the maintained alternative. Still the default. A composer fix on a package with zero dependents does not create an upgrade path; an actively maintained FullCalendar wrapper with a published compatibility matrix converts open-ended risk into a version pin we can track. Recommend unless Timex offers a specific capability the alternative lacks.
2. Fork and vendor. Materially cheaper than it was before 1.1.7 — the dependency-constraint archaeology is already done upstream, so a fork starts from a resolvable baseline. Remaining work: bump Filament/Livewire constraints, port the service provider registration to the current plugin contract, replace Mix with Vite publishing, add a panel-boot smoke test. Budget 2–4 engineer-days, down from 2–5, plus ongoing ownership.
3. Build in-house. Still a bounded 3–5 day task with the advantage that we own the upgrade path. Beats the fork when the fork would need the same porting work plus comprehension debt.

Compatibility checklist — reordered, because the install gate has moved. Panel boot with the plugin registered on our Filament version is now check one, not check three. Then: Livewire 3 render cycle (the v2→v3 lifecycle and request-handling changes are a common silent break, and a Laravel-10-only fix would not have surfaced them); asset publishing under Vite; Tailwind class purge correctness; and one end-to-end render with a non-trivial event set. Composer constraint resolution moves to a pre-check we expect to pass.

Sequencing.

• Phase 0 — spike (0.5 day). Isolated Laravel 10 + current Filament sandbox. Expect the install to succeed; instrument the panel boot and capture the exact runtime failure. The spike's deliverable changes from "does it install" to "where does it break, and is the break in the plugin contract or the view layer."
• Phase 1 — decision gate. If the spike boots and renders, proceed. If it installs but fails to boot — the now-likelier outcome — choose between fork and substitute against the feature checklist. Since the composer layer is resolved, a failure here is unambiguous evidence of Filament-version incompatibility, which makes the fork/substitute call cleaner than it was previously.
• Phase 2 — feature parity definition. Minimum viable calendar: which model, which fields, read vs write, which views, timezone policy. Unchanged, and still the guard against an unbounded fork.
• Phase 3 — feature flag, internal route first. Unchanged and now more important: the install-success/boot-failure pattern is exactly the case where a developer's local run looks fine and the shared panel does not.
• Phase 4 — pin and document. Record fork commit or version constraint, add a dependency-review note, re-evaluate at each Filament major.

Operational Impact

Maintenance. Still the dominant cost. 1.1.7 is a positive maintenance signal — the package is not abandoned, and the maintainer responds to install-level breakage — but it is not evidence of a compatibility program. Nothing in the release suggests anyone is testing against Filament 3 or 4, and zero dependents means no downstream project is exercising the code against modern dependency sets. If we fork, we now own a slightly healthier starting point; if we substitute, we inherit a maintainer with an actual cadence. Assign a named owner before merging regardless.

Support. Unchanged: MIT, no vendor, no SLA, no security contact, best-effort issue response. Escalation path is "we fix it." Acceptable for internal admin convenience, unacceptable for customer-facing or revenue-adjacent surfaces. The supply-chain point stands — an unmaintained JS calendar dependency is not being audited by anyone, so keep it in dependency scanning rather than exempting it.

Scaling. Unchanged, because the release touches only a composer constraint. The scaling question lives in the query, not the plugin: (a) unbounded date-range queries feeding a month view degrade as event volume grows — enforce server-side range bounds and indexes on start/end; (b) payload size — thousands of events serialized into a Livewire payload stresses the snapshot/hydration path; (c) rendering — dense months with overlapping events become a browser problem before a database one. Window data per visible range and cap events per cell.

Failure modes to design against.

• Panel boot failure after install — highest severity, whole-admin outage, and now the most probable failure mode given that composer resolution is fixed. Mitigation: feature flag, staging-first, CI smoke test that boots the panel with the plugin registered.
• Silent empty calendar when the event source query throws or a timezone conversion is wrong — low severity, high confusion, reported late. Mitigation: explicit empty- and error-state UI plus a log line on the query path.
• Timezone/DST drift on recurring or all-day events — data-correctness failure that erodes trust in the whole calendar. Mitigation: single storage convention (UTC in DB, user timezone at render) and a test across a DST boundary.
• Asset pipeline breakage — calendar renders unstyled or blank after a Vite/Tailwind change. Unaddressed by 1.1.7; mitigation is a visual smoke check in the release checklist.
• Regression on the next Laravel bump — a composer constraint patched in a point release can regress in a point release; pin exactly and re-test after any upstream update.

Ramp-up. Unchanged. For a Filament-fluent developer, comprehension is a half-day — one page, one component, one view. Modernization is multi-day, and 1.1.7 shaves maybe half a day off it by removing the dependency-constraint archaeology. The trap remains that comprehension is cheap and modernization is not. Teams without Filament experience should not use this package as a learning vehicle.

Recommendation. Softened, not reversed. 1.1.7 clears the composer gate on Laravel 10, which is a necessary and previously missing precondition — so run the Phase 0 spike on a current Laravel 10 + Filament sandbox, expecting the install to succeed and testing specifically for panel boot and Livewire 3 render. If the spike boots and renders, this becomes a viable short-term option on a strict version pin with a named owner. If it installs but fails to boot — the likelier outcome — default to the maintained FullCalendar alternative and fall back to a bounded in-house page. Reserve the fork path for the case where Timex has a specific capability we cannot get elsewhere; 1.1.7 lowers that fork's cost but does not change the ownership burden it creates.