New package proposal: yiisoft/schedule — recurring tasks for Yii 3

[KalimeroMK]

At work we are migrating a large project from Yii 2 to Yii 3, and one capability we lost in the move is scheduling: omnilight/yii2-scheduling (316 stars, 1.1M downloads) hard-requires yiisoft/yii2, so it simply cannot be installed in a Yii 3 application. This package started as our partial solution to that problem, extracted and generalized.

Proposal: a new framework-agnostic package, yiisoft/schedule — recurring tasks defined in PHP, driven by a single cron entry (schedule:run) or a daemon (schedule:work).

Design sketch, borrowing the parts of Symfony Scheduler that proved out:

• TriggerInterface as a pure function (last run → next run), with cron (dragonmantank/cron-expression), periodic-interval and callback implementations
• Tasks as callables, console command names, or queue messages pushed via yiisoft/queue
• Overlap prevention via yiisoft/mutex, missed-run catch-up via any PSR-16 cache, PSR-14 events (where Sentry cron check-ins plug in)
• Commands registered through yiisoft/yii-console params — zero application wiring

A working implementation with tests and full QA tooling is up at KalimeroMK/yii-schedule — happy to transfer it to the yiisoft org, or keep it as a community package if you prefer.

Mainly looking for feedback on: the naming, the queue integration boundary, and whether this is something you'd want as an official package.

[zoranbogoevskimkd]

@samdark your thoughts

[samdark]

@zoranbogoevskimkd I personally find it very inefficient to kickstart PHP and framework every minute only to check that nothing is scheduled and die and prefer real crontab.

Daemon looks interesting, but I have a few concerns:

1. Task execution is blocking, so if we have two entries at exactly 8:00, only one will be executed at the scheduled time and another will wait, which could be critical. The crontab starts tasks at exactly 8:00 no matter how many there are.
2. Tick-by-tick sleeping could be replaced with analyzing the schedule and sleeping to the next scheduled run instead. This way you can avoid ~86K ops daily.

[samdark]

Overall, having plain crontab in the repository and installing it on deployment is way leaner and simpler. Atomicity can be handled with flock.

[samdark]

https://t.me/samdark_comments/4908

[samdark]

Still not decided since that's my personal preference. Community might think otherwise.

[KalimeroMK]

@samdark For static, environment-independent jobs that's true — plain crontab + flock wins, and the package doesn't try to replace that case. schedule:run is exactly one cron entry, so it composes with the same deployment model.

Where crontab stops being leaner is when scheduling touches the application: container-built callables, config or feature flags deciding whether a task exists at all, overlap prevention via the app's mutex, missed-run catch-up after downtime, queue messages through yiisoft/queue, and PSR-14 events for monitoring (e.g. Sentry cron check-ins). In shell, each of those becomes a per-project reimplementation.

So the pitch isn't "cron, but in PHP" — it's "one cron entry, tasks defined next to the code they run."

[samdark]

Aha. It makes sense. Let's have it under yiisoft.

[KalimeroMK]

@samdark Ready to transfer KalimeroMK/yii-schedule to the yiisoft org whenever you are — I'll need an invite with repo creation rights. After the transfer I'll follow up with the package rename to yiisoft/schedule (composer name, Packagist, badges).