Cron Bundle Laravel Package

Product Decisions This Supports

First, the framing correction that gates everything else: rikudou/cron-bundle is a Symfony 6 bundle, not a Laravel package. It has no service provider, no publishable config, and no Schedule integration. For a Laravel roadmap it is a design reference, not a dependency. That single fact should be stated up front in any decision doc, because it changes the decision from "adopt or not" to "read or ignore."

With that caveat, the package informs these product decisions:

• Build vs. buy for user-defined scheduling. The real product question is whether admins or tenants should be able to define their own recurring jobs (a cron expression + a command/action + a payload) instead of engineers hardcoding entries in app/Console/Kernel.php or routes/console.php. This bundle is a clean, small example of that pattern: persist the job definition in configuration, evaluate every minute, dispatch only what's due. It is a blueprint, not a component.
• Roadmap prioritization: is dynamic scheduling in scope at all? If yes, budget one sprint for a thin internal scheduler on top of dragonmantank/cron-expression — which Laravel already pulls in transitively via Illuminate\Console\Scheduling. If no, close the ticket and cite this evaluation. Either way, the decision is now made cheaply.
• Use cases it maps to (conceptually): tenant-configurable recurring reports/exports, customer-defined reminder cadences, per-account polling intervals, and any deployment where editing a host crontab is impossible (immutable containers, PaaS, autoscaled app tiers). These are real product surfaces; the package just isn't our vehicle for them.
• Use cases it does not justify: anything requiring retries, backoff, distributed locking, run history, alerting, or per-tenant timezone correctness. This is a cron expression evaluator plus a console command — not a job orchestration platform. Do not let the name set expectations with stakeholders.
• Adoption signal as a supportability verdict. Three stars, zero dependents, a single maintainer, an overall score of 0.105. Low stars don't condemn the code — the scope is genuinely small and may be fine — but they do mean no production validation and no one to call. A PM buys supportability, not cleverness; that is the deciding input here.

Recommendation: Do not add it as a dependency. Spend 30–60 minutes reading src/ as a pattern reference, then build internally on dragonmantank/cron-expression, which is already installed and has a real maintenance and CVE-response path.

When to Consider This Package

Consider it only when all of the following hold:

• The service is Symfony 6.x and will remain there for the dependency's useful life.
• The requirement is genuinely minimal: evaluate a cron expression each tick and invoke a console command. No retries, no overlap prevention, no distributed coordination, no admin UI.
• The team accepts vendoring or forking it. At this adoption level, assume the maintainer walks away and plan for it.
• The eventual framework upgrade cost is acceptable — the bundle is versioned to Symfony 6 and becomes a migration liability at Symfony 7/8.

Look elsewhere — or build — when any of these are true:

• You are on Laravel. Use dragonmantank/cron-expression directly (already present via the scheduler), or spatie/laravel-schedule-monitor if you need visibility. This package offers Laravel nothing that isn't already in the framework.
• You are on Symfony 6.3+. The first-party symfony/scheduler component covers recurring messages and is core-team maintained. A third-party bundle is strictly worse on supportability.
• You need operational guarantees. Run history, missed-run alerting, per-tenant timezone correctness, idempotency, and withoutOverlapping semantics are out of scope and would be rebuilt by us anyway.
• You need a security or compliance review. Zero dependents means zero external scrutiny — every line is effectively unreviewed third-party code in a privileged execution path.

How to Pitch It (Stakeholders)

For executives (two sentences): We evaluated a small open-source library for letting customers schedule their own recurring jobs. It is a Symfony-only component with three GitHub stars, no downstream users, and a single maintainer, so we are not adopting it — we will spend roughly one sprint building the equivalent on top of a library we already ship, which removes the abandonment and upgrade risk at a fraction of the long-term cost.

For engineering (the ask): Don't take the dependency. Read RikudouCronBundle for the pattern — a persisted cron expression plus a per-minute schedule:run-style command that filters to due jobs — then implement it in-house against dragonmantank/cron-expression. Scoping notes:

• Scope v1 to expression parsing, due-job selection, timezone handling, and a single lock per job. That is the entire value of the reference implementation.
• Explicitly out of scope for v1: retries, backoff, run-history UI, multi-node coordination. Add symfony/lock or Laravel's onOneServer() when we actually need them.
• Target the framework we already run. On Laravel this requires no new dependency at all — dragonmantank/cron-expression is already installed.
• Success criteria for the spike: a DB row holding a cron string and a command name reliably fires within one tick, and we can explain in one paragraph why we own that code instead of importing it.

For the record: log this package as evaluated and not adopted, with the reason "framework mismatch + no supportability signal," so the next person doesn't re-run this analysis.