Schedule Laravel Package

Technical Evaluation

Architecture fit. rennokki/schedule is a thin, trait-based domain layer for Eloquent. You add a Schedulable trait to a model (Worker, Room, Vehicle, Technician), publish a migration, and the package persists schedule rows with start/end timestamps. Availability is then queried per model over a time window. Architecturally this is a good shape for us: no queues, no external services, no background daemons, no vendor lock — just a table and a trait. It slots into the same pattern we already use for tagging and auditing concerns, so the blast radius on our existing codebase is close to zero. The concern is not the shape, it is the depth: the package models a flat list of time ranges, not a calendar. Recurrence, shift templates, blackout dates, approval workflows, and multi-timezone correctness are all outside its scope and would have to be built around it.

Integration feasibility. Mechanically trivial: composer require, publish the migration, add the trait, start writing schedule rows. The real work is environmental. The last release is February 2019 — pre-dating Laravel 6 — so its composer.json constraints are almost certainly pinned to PHP 7.1–7.3 and Carbon 1.x. Installing it into a current Laravel 10/11/12 application will likely fail dependency resolution outright, and forcing it with --ignore-platform-reqs would drag Carbon 1 into a Carbon 2/3 codebase, which is a runtime hazard, not a warning. I would treat "does it install cleanly on our target Laravel version" as a same-day spike, not an assumption.

Technical risk. The dominant risk is that this is an archived repository with a single historical maintainer and no security response path. There will be no CVE patches, no PHP 8.3+ fixes, no Laravel 12 compatibility work, and no upstream answer to a subtle DST bug. Secondary risks are semantic: overlap detection performed in PHP rather than the database creates a race condition under concurrent writes (two schedulers can double-book a worker); the API is availability-query oriented, not constraint-enforcement oriented. Tertiary risk is schema: an unbounded append-only schedule table with polymorphic keys needs deliberate indexing or availability queries degrade as history accumulates.

Key questions to resolve before commitment.

1. Do we need recurring shifts or templates, or genuinely ad-hoc ranges? If recurrence is required, this package is at best a storage schema.
2. What are the timezone and DST requirements? If workers cross zones or shifts straddle DST boundaries, we need to know whether the package stores naive or zoned timestamps.
3. Is availability advisory (a UI hint) or binding (a hard constraint preventing double-booking)? Only the latter requires DB-level exclusion constraints.
4. What is our Laravel version floor for the next 24 months, and are we willing to own a fork indefinitely?
5. Is there an audit/approval requirement (who changed whose schedule, and when)?

Integration Approach

Stack fit. Good conceptual fit for a Laravel monolith or modular monolith backed by MySQL or Postgres. The polymorphic trait pattern matches our existing Eloquent conventions. It does not fit a service-oriented architecture that would need schedule data exposed across bounded contexts — there is no API, event, or DTO surface, only models and query helpers.

Migration path. Three options, in ascending cost:

Given the archive status, I would default to fork or reimplement and treat adoption-as-is as the exception that has to be argued for.

Compatibility. Validate explicitly: PHP version constraint, Laravel illuminate/* constraint, Carbon major version, and whether the migration uses column types still supported (e.g. timestamp nullability defaults changed in MySQL 5.7+/8). Also confirm the polymorphic morphTo key types match our existing ID strategy — if we use UUIDs or ULIDs anywhere, the published migration's unsignedBigInteger keys will need rewriting.

Sequencing.

1. Spike (1 day): branch, attempt install on our target versions, run the migration, exercise the trait's availability API against a seeded dataset.
2. Requirements gap analysis (2–3 days): map recurrence, timezone, enforcement, and audit needs against package capability; produce a build/fork/adopt recommendation.
3. Decision gate: go/no-go with a named owning team and an explicit fork-maintenance commitment if we proceed.
4. Implementation: schema plus DB-level exclusion constraint first, then the domain logic, then the read API.
5. Backfill/cutover: only relevant if replacing an existing scheduling source.

Operational Impact

Maintenance. This is the headline cost. "Archived" means we inherit 100% of maintenance from day one, including future PHP and Laravel upgrades. A fork must have an owner, a versioning scheme, and a documented policy for when we rebase or abandon it. Expect security scanning tooling to flag the dependency as unmaintained, which will generate recurring review noise and may block release pipelines with a strict policy.

Support. No upstream fixes, no maintainer response, no roadmap. Community knowledge is thin at 155 stars — Stack Overflow coverage will be near zero, so every non-obvious behaviour becomes internal archaeology. Budget for reading the source rather than searching for answers; the codebase is small enough that this is feasible, which is the one thing working in its favour.

Scaling. The cost driver is the availability query, not write volume. Availability lookups must be index-backed on (schedulable_type, schedulable_id, start, end); without that, per-worker availability checks in a list view become N+1 scans over a growing table. Plan for retention/archival of historical schedule rows. If we add hard double-booking prevention, that belongs in a database exclusion constraint (Postgres EXCLUDE USING gist with tstzrange) rather than application-level checks — the package gives us nothing here.

Failure modes to design against.

• Silent timezone drift — naive timestamps plus a mixed-timezone workforce produces off-by-hours availability with no error. Store UTC plus an explicit zone per schedule.
• DST boundaries — a shift spanning a DST transition is 60 minutes longer or shorter than its nominal duration; duration logic must be zone-aware.
• Overlap race condition — concurrent writes double-book a resource; only a DB constraint closes this.
• Carbon 1 contamination — if forced into a Carbon 2/3 app, date arithmetic behaves differently in ways that surface in production, not in tests.
• Unbounded table growth — availability queries slow monotonically without retention policy.

Ramp-up. Learning the package API is a half-day task — the surface is small and idiomatic. That is not the ramp-up risk. The ramp-up risk is organisational: the team must absorb ownership of a dated dependency and the surrounding domain logic (recurrence, timezones, enforcement) that the package deliberately does not provide. I would size the true effort as "build a scheduling domain, using this package's migration as a starting reference" rather than "integrate a package."

Recommendation. Do not adopt as a live dependency. Run the one-day spike; if the schema and trait shape suit our model, fork it internally and own it with DB-level enforcement and timezone handling added. If recurrence or approval workflows are in scope, skip the fork and build directly — the package's value contribution in that scenario is a single migration file.