- Can I use m-adamski/symfony-schedule-bundle in a Laravel application?
- No. It is a Symfony bundle built on the HttpKernel and DI compile pipeline (Bundle::build, Extension::load, tagged services, compiler passes), and Laravel has no Bundle concept at all. Laravel's container is Illuminate\Container driven by service providers, so the package cannot be installed and functional inside a Laravel app. Treat the repository as a design reference, not a runtime dependency.
- What Laravel version does this package support?
- None. The package targets Symfony, not Laravel, so no Laravel version is supported. On Laravel 10 or 11 with PHP 8.1 to 8.3, use the built-in Illuminate\Console\Scheduling\Schedule instead.
- How do I install and register this bundle in a Symfony application?
- Install it with composer require m-adamski/symfony-schedule-bundle, then register the bundle in config/bundles.php and wire your schedule definitions through the bundle's DI extension. It assumes a full Symfony kernel with compiler passes and cache warmup, so it will not boot outside that context. In a polyglot monorepo, keep it isolated inside the Symfony service with its own cron entry per environment.
- What is the Laravel equivalent of this Symfony cron scheduling bundle?
- App\Console\Kernel::schedule() with the Illuminate Schedule builder. It gives you ->cron('0 * * * *'), ->withoutOverlapping(), ->onOneServer(), ->runInBackground(), before and after hooks, plus the schedule:list, schedule:test, and schedule:work commands, all driven by a single schedule:run cron entry. That covers roughly 95 percent of real scheduling needs.
- Does it work with Symfony 7, Symfony 8, or PHP 8.4?
- Unknown. The last release was 2024-02-02, there is no test corpus signalling readiness for newer Symfony or PHP versions, and the bundle hooks into upstream internals that shift on minor bumps. For Symfony 6.3 and later, the first-party symfony/scheduler component is the safer bet.
- Is this bundle actively maintained and safe for production?
- Be cautious. It has 13 stars, zero dependents, a single maintainer, no published security policy, and no downstream battle-testing, so the bus factor is one. The MIT license makes it forkable, which mitigates but does not eliminate the risk. Do not adopt it without owning a fork and agreeing an SLA for patches.
- How does it compare to Symfony's symfony/scheduler component?
- symfony/scheduler is first-party and stable from Symfony 6.3 onward, offering #[AsSchedule], ScheduleProviderInterface, and RecurringMessage for recurring work. It is the canonical Symfony answer, and third-party bundles in this niche are being squeezed out of their own space. For a Laravel team, the equivalent answer is Laravel's native Schedule, not a Symfony bundle.
- Does it handle timezones, DST, and preventing overlapping runs across multiple servers?
- Not with any documented confidence. Timezone and DST handling, overlap prevention, and missed-window catch-up are exactly where homegrown schedulers fail silently, and there is no published test suite to verify behaviour. In Laravel, onOneServer() requires a shared cache driver and withoutOverlapping() uses a cache lock, so multi-node guarantees come from your cache layer, not the scheduler itself.
- How do I test scheduled tasks if I adopt this bundle or port the pattern to Laravel?
- In Laravel, use schedule:list to inspect what is registered and schedule:test to run a single command by name or index. If you port the attribute-based declaration idea, cover cron parsing, DST edges, overlap locks, and missed windows with tests before shipping. Budget roughly three to five dev-days for an attribute layer on top of Kernel::schedule(), tests included.
- Will it cause Composer conflicts in a Laravel project, and how hard is the idea to port?
- Yes, in a Laravel app it would pull and pin symfony/console and symfony/dependency-injection, which Laravel already pins transitively, creating resolution conflicts for no functional gain. Porting the concept is cheap because it is just a cron-expression registry, a runner, and a lock. A one to two day spike on top of Laravel's Schedule is enough to confirm whether you actually need anything beyond the built-in scheduler.