Product Decisions This Supports
- Roadmap signal, not a dependency. The package addresses a legitimate product need — declarative, version-controlled cron definitions instead of hand-edited crontabs and untracked shell scripts — but with 10 stars, 0 dependents, and an archived repo, it should be treated as prior art rather than code we build on. Read the config schema for ideas; do not ship the library.
- Build-vs-buy resolves to "use the framework." Laravel's scheduler (
routes/console.php / Kernel::schedule) and Symfony's Schedule component cover the same use case natively, with active maintenance. There is no buy decision here: the "buy" option is already in the framework.
- Framework mismatch is a scoping input. Despite being filed alongside Laravel/PHP packages, this is a Symfony bundle — not a Laravel package. Any roadmap item or ticket that references it needs re-scoping before estimation; treat the reference as a red flag on the ticket.
- Informs dependency hygiene work. Archived status with zero dependents is exactly the profile our dependency policy should auto-reject. This is a good concrete example to cite when proposing a "no archived dependencies without a time-boxed exception" rule.
- Use cases it nominally covers: periodic batch jobs, maintenance tasks, scheduled syncs. All of these are better served by the scheduler already in the stack, plus the operational layer (overlap locks, alerting, run history) this package does not provide.
When to Consider This Package
Consider it only if:
- You maintain a legacy Symfony 2/3 application that already depends on it and migration cost exceeds the risk — and even then the decision is freeze, wrap, and isolate, not adopt.
- You want to read the source as reference material for modeling cron schedules in YAML/PHP config.
- You are building a disposable internal tool where zero upstream support and no security patching are acceptable.
Look elsewhere — which is nearly always — if:
- You are on Laravel. It is a Symfony bundle; the framework mismatch is disqualifying on its own.
- You need PHP 8.x compatibility, security patches, or any maintenance guarantee. Archived means none of these will arrive.
- You need operational maturity: overlapping-run protection, failure alerting, distributed locks, retries, run history. This predates and does not address any of it.
- Your compliance or security posture requires an actively maintained dependency with a support path.
How to Pitch It (Stakeholders)
Executive summary: We evaluated sbk/cron-bundle for scheduling configuration and do not recommend adoption. It is an archived, unmaintained Symfony bundle with 10 stars and zero downstream dependents; its low composite score places it in the unreliable band. Archived status means no security patches, no PHP-version upkeep, and no maintainer to escalate to — an unacceptable supply-chain risk for anything customer-facing.
The idea is sound; the artifact is not. Defining scheduled jobs declaratively in config files — versioned in Git and reviewed like code — is the right pattern. Both Laravel and Symfony now ship it natively, so we get the benefit without the dependency.
Recommendation: Close the dependency question. If scheduling work is on the roadmap, invest in the framework-native scheduler plus the operational layer that actually differentiates us — overlap locks, failure alerting, and run history — rather than third-party glue.
For engineering: No integration work. If a legacy Symfony service already uses it, wrap the call site behind our own scheduler interface so it can be swapped during the next maintenance window, and add a policy rule requiring a time-boxed, owner-assigned exception for any archived package.