- Is sbk/cron-bundle a Laravel package?
- No. sbk/cron-bundle is a Symfony2 bundle that ships a DependencyInjection extension, service definitions, and a configuration tree built for the Symfony kernel. It has no Laravel service provider, no Artisan integration, and no autoloading hook for a Laravel app. Treat any Laravel use as a port of its ideas rather than a direct install.
- Does sbk/cron-bundle work with Laravel 11?
- It does not. The repository is archived, targets Symfony 2.x and 3.x era tooling, and will not load cleanly in a current Laravel stack on PHP 8.x. Laravel 11 already ships a first-party Task Scheduler through routes/console.php and app/Console/Kernel.php. Rewriting the config-driven idea against a maintained cron library is the only realistic path.
- How do I install sbk/cron-bundle with Composer in a Laravel project?
- You can run composer require sbk/cron-bundle, but inside Laravel you end up with an unregistered Symfony bundle. There is no service provider for auto-discovery and no facade or config file Laravel recognizes. Wiring it up means writing an adapter around an archived dependency, which almost never pays off.
- Is sbk/cron-bundle still maintained?
- The GitHub repository is archived, meaning the maintainer has stopped accepting issues and pull requests. It has zero dependents and roughly ten stars, so there is no public evidence of anyone running it on a supported framework version. Archived also means no CVE response, no dependency scanning, and no PHP 8 compatibility work.
- Can sbk/cron-bundle replace Laravel's task scheduler?
- No. Laravel's schedule() API in app/Console/Kernel.php or routes/console.php already handles cron definitions, overlap protection, timezones, and output logging in one first-party entry point. sbk/cron-bundle only offers Symfony config-driven cron declaration, and it is archived. Duplicating native functionality with a dead dependency is negative ROI.
- What are good alternatives to sbk/cron-bundle for cron parsing in Laravel?
- dragonmantank/cron-expression is the mature library Laravel itself depends on for parsing and validating cron expressions. For scheduling, use Laravel's native Task Scheduler, or the Symfony Scheduler component on Symfony 5.4 and newer. Both are actively maintained and cover DST transitions, timezone boundaries, and overlap handling.
- How do I validate a cron expression in Laravel?
- Use dragonmantank/cron-expression, which is already a transitive Laravel dependency. CronExpression::isValidExpression returns a boolean, and CronExpression::factory followed by getNextRunDate gives you the next scheduled time. Laravel's scheduler uses this same library internally, so a separate bundle adds nothing.
- Does sbk/cron-bundle support PHP 8?
- Almost certainly not without edits. The bundle is archived and targets Symfony 2.x and 3.x, which reached end of life in 2019 and 2021 respectively. Making it load on PHP 8.x in a modern LTS stack is a multi-day effort with no upstream support. For a production scheduler, that is an unacceptable supply-chain position.
- Is it safe to use sbk/cron-bundle in production?
- No. An archived bundle with no dependents means unresolved edge-case bugs in cron scheduling can surface silently in production. Config-driven crons also decouple job definitions from the crontab entry point, so a stale config cache or missing runner means jobs simply do not fire. Security review is unlikely to approve an archived dependency when a first-party scheduler exists.
- How do I migrate from sbk/cron-bundle to Laravel's scheduler?
- Translate each configured cron entry into a schedule() call in routes/console.php or app/Console/Kernel.php using cron or the frequency helpers. Add withoutOverlapping and timezone where the old config implied them, and wire onFailure or emailOutputTo so silent failures become visible. Then remove the bundle and confirm the single crontab entry still runs schedule:run every minute.