Scheduler Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony bundle, not a Laravel package. The Composer name (multiinfo/scheduler-bundle) and repo (monark-it/SchedulerBundle) both point at a Symfony-style bundle, which means none of Laravel's conventions apply — no extra.laravel.providers auto-discovery, no php artisan vendor:publish, no config file dropped into config/. If you are evaluating it for a Laravel codebase, the realistic answer is that you would be porting ideas, not installing the package; for scheduling inside Laravel you already have Illuminate\Console\Scheduling\Schedule and a single schedule:run cron entry, and a 1-star, 0-dependent bundle is not a reason to introduce a second scheduler.

If you are in a Symfony app (or maintaining one that already pulls this in), the first steps are:

1. composer show multiinfo/scheduler-bundle and read its composer.json — check the symfony/* version constraints and the type (symfony-bundle). That tells you immediately whether it will even boot on your framework version.
2. Read README.md if there is one; given the "MIT Scheduler Bundle" description and single-star count, expect it to be thin or absent.
3. Open src/DependencyInjection/Configuration.php (or Configuration.php at the bundle root) — this is the config tree. Every knob the bundle exposes is defined there, and it is more reliable than any docs.
4. Look at src/Command/ for the console entry points. A scheduler bundle almost always ships something like an schedule:run-style command; that command is your integration point with cron.
5. Check src/Resources/config/ for service definitions and any Doctrine entity/mapping if tasks are persisted.

First use case to validate: register the bundle in config/bundles.php, run bin/console list and confirm the bundle's commands appear, then define the simplest possible scheduled job and invoke the run command manually from the CLI. If that path is not obvious within 30 minutes, treat the package as undocumented and decide accordingly.

Implementation Patterns

Because the package is effectively undocumented in public, the patterns below are the ones that hold for Symfony scheduler bundles generally; verify each against the actual source before relying on it.

Cron as the driver, bundle as the logic. The standard shape is: one crontab entry (* * * * * cd /app && bin/console <vendor>:scheduler:run) that ticks every minute, and the bundle decides which registered tasks are due. Do not create one cron entry per task — that defeats the purpose and spreads scheduling logic across the host. Keep the bundle's config as the single source of truth for intervals.

Wrap existing commands rather than rewriting them. The highest-value pattern is registering commands you already have (app:sync-orders, app:send-digests) as scheduled tasks, so the bundle owns when and the command owns what. This keeps tasks testable via bin/console app:sync-orders independently of the scheduler.

Separate "define" from "execute" in your own code. If the bundle lets you register tasks programmatically (a compiler pass or a Scheduler service you inject), put all task registration in one dedicated service or a small Scheduler/ namespace. When the bundle is abandoned — a real risk at 1 star and 0 dependents — you want the swap to a hand-rolled cron or symfony/scheduler to touch one file.

Locking and idempotency belong to you. Assume the bundle does not protect against overlapping runs unless you can point at the code that does. Add flock, a Symfony Lock keyed on task name, or make each task idempotent. Overlap is the failure mode that bites in production, not mis-scheduling.

Observability. Wire the bundle's task execution into your existing logging and metrics. At minimum you want: task started, task finished, duration, exit code. A scheduler that fails silently is worse than no scheduler.

Migration path. Symfony now ships symfony/scheduler as a first-party component. If this bundle is doing anything non-trivial, prototype the same tasks on symfony/scheduler before committing — the built-in component has a supported upgrade path.

Gotchas and Tips

• Framework mismatch. Installing this in Laravel will not work as intended; bundles register through Kernel::registerBundles(), not a service provider. Don't try to bridge it. If the underlying ideas are useful, reimplement them with Schedule::call() / Schedule::command().
• Maintenance risk. 1 star, 0 dependents, a description that just restates the name, and a multiinfo vendor prefix (MultiInfo is an SMS/payments provider; monark-it is a Moldovan dev shop) all suggest an internal package published to Packagist for convenience. Assume no security response, no Symfony-version bumps, and no semver discipline. Pin it exactly ("multiinfo/scheduler-bundle": "1.x.y") and vendor-review the diff before any update.
• Persistence surprises. If tasks or run history are stored in Doctrine, you will need migrations — check src/Resources/ for mapping files or a Migrations/ directory. Missing migrations is a common first-run failure.
• Timezone. Cron fires in the host's timezone; the bundle may interpret intervals in PHP's default. Set date_default_timezone_set / php.ini explicitly and confirm the two agree, or jobs will drift by hours after a DST change.
• Debugging. Run the scheduler command with -vvv and, if it supports it, a --dry-run or --dump flag to see which tasks it considers due. If no such flag exists, that absence is itself a signal about maturity.
• Config quirks. Read Configuration.php rather than guessing YAML keys; Symfony's config tree is strict and will throw on unknown keys, which at least fails loudly. Watch for required scalar values that silently coerce (e.g. "60" vs 60).
• Extension points. Compiler passes (src/DependencyInjection/*CompilerPass.php) and tagged services are how you extend a bundle like this without forking. Look for addCompilerPass calls in the bundle class — tagged task registration is the most common extension seam and the one you'd want if you adopt it.
• Testing. Do not unit-test through the scheduler. Test the wrapped commands directly, and use a single integration test that asserts the bundle picks up your registered tasks (by name/count), so a bundle upgrade that breaks discovery fails in CI rather than at 3 a.m.