Schedule Bundle Laravel Package

Product Decisions This Supports

• Feature scoping: scheduling moved into application code. Concretely evaluates the "define recurring work in PHP, not crontab" capability for a Symfony codebase. Directly applicable when scoping nightly syncs, digest emails, subscription renewal runs, cache warmers, or reconciliation jobs that today live as opaque server cron entries with no review trail or environment parity.
• Roadmap input: crontab consolidation and operational toil. If the roadmap carries items about hidden jobs, drift between staging and production, or "why didn't the nightly job run?" incidents, this package is a working demonstration of the migration target — ScheduleProviderInterface services collected by Symfony's autoconfigure, executed by a single schedule:run entry point, all under version control and code review.
• Build vs. buy vs. borrow — and the answer here is borrow. MIT-licensed, archived, zero stars, zero dependents, README-level maturity. This is not a vendor evaluation; it is a decision about whether to (a) adopt the Laravel Console Scheduling model, (b) fork and own this bundle, or (c) use Symfony's first-party Scheduler component. Frame it to stakeholders that way and the conversation stays honest.
• Risk weighting for business-critical jobs. The distinguishing features — setMaxLockTime() for overlap protection, fluent cadence (everyMinute(), everyFiveMinutes()), argument passing via command('x', ['-v']) — are exactly the parts that matter when concurrent runs corrupt data (billing, inventory, payouts). This gives the PM a concrete yardstick for whether a scheduling approach is production-grade or a sleep loop in disguise.
• Team and hiring velocity. If the org runs Laravel and Symfony side by side, or is migrating Laravel engineers onto Symfony, the familiar DSL is an on-ramp that measurably lowers ramp-up cost. That is a velocity argument as much as a technical one, and worth naming explicitly in a build-vs-buy memo.
• Scheduled work as first-class product surface. Schedules living in src/Schedule/*Provider.php under Git support review, testing, and rollback. This is a governance improvement the PM can claim regardless of which implementation wins.

When to Consider This Package

Consider it when all of the following hold:

• You are on a Symfony application and want scheduled work expressed in PHP with a single schedule:run entry point rather than scattered crontab lines.
• You specifically want the Laravel-style fluent API and provider/autoconfigure pattern — either because the team is Laravel-fluent or because you want to prototype that ergonomics quickly.
• You are treating it as reference material or a fork candidate, not a long-term dependency. Archived, [READ-ONLY], 0 stars, 0 dependents, no Flex recipe, no documented compatibility matrix for PHP/Symfony/illuminate/* versions.
• The scheduling surface is modest — a single host or a small fleet — and you have an identified internal owner willing to carry maintenance if you fork.
• You have, or will build in the same cycle, run history and failure alerting. The bundle schedules commands; it does not solve observability. An unmonitored scheduler is worse than cron, because it hides its failures inside the app.

Look elsewhere when:

• Maintenance and security posture are gating. Archived means no patches, no CVE response, no version bumps. For a regulated, SLA-bound, or customer-facing product this fails dependency review outright without an explicit fork-and-own commitment.
• A first-party alternative fits: Symfony's native Scheduler component (available in modern Symfony releases), Symfony Messenger with a scheduler transport, or infrastructure scheduling (Kubernetes CronJobs, systemd timers, cloud schedulers). Default to the native path unless there is a specific reason not to.
• You need distributed, queue-backed, at-scale scheduling with alerting out of the box. This is a thin convenience layer over the cron and heartbeat concerns you would otherwise own.
• Strict supply-chain or zero-third-party policies apply — an unmaintained bundle with transitive illuminate/* coupling will not clear review.
• Your team is Symfony-native. The idioms are foreign, you pull Laravel framework packages into a Symfony dependency graph, and autoconfigure must stay enabled or providers silently fail to register — producing an empty schedule with no error.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a low-cost opportunity to move scheduled jobs out of opaque server cron and into version-controlled application code, which improves auditability, code review, and environment consistency. There is a ready-made pattern for this — a small MIT-licensed Symfony bundle that ports Laravel's well-known scheduling API — and it costs us nothing to evaluate because it is not a vendor commitment. One caveat up front: the package is archived and unmaintained, so the actual recommendation is to adopt the pattern — most likely through Symfony's own Scheduler component, or a small internal fork we own — rather than take a long-term dependency on this specific library. Net effect: less operational toil and fewer "the nightly job didn't run" incidents, at low engineering cost and with an easy exit if we change direction.

To engineering: Integration is genuinely small — composer require, register the bundle in config/bundles.php (no Flex recipe was ever published), then implement ScheduleProviderInterface in one or more autoconfigured services; ScheduleInterface mirrors Laravel Console Scheduling, so anyone with Laravel background is productive on day one. You get argument passing, per-task locks via setMaxLockTime(), and overlap protection — the parts that actually bite in production. Two caveats to plan around. First, it is archived: treat it as a spec. Second, it transitively pulls illuminate/support, illuminate/console, and illuminate/container into our Symfony dependency graph with no published compatibility matrix, so validate constraints empirically before committing. Proposed path: pilot the API shape in a throwaway branch, smoke-test provider discovery and overlap locking with two concurrent runners, then decide on a documented scorecard between Symfony Scheduler and an internal pinned fork. Either way, sequence this behind run logging and failure alerting — a scheduler we cannot see is a scheduler we cannot trust.

Recommendation: Evaluate, do not adopt as-is. Use the package as the reference for API ergonomics, prototype against Symfony's native Scheduler, and make the build-vs-fork decision this cycle while the migration cost is still near zero.