Task Bundle Laravel Package

Getting Started

Read the repo before writing a line of code — this is a Symfony bundle, not a Laravel package, so "getting started" means deciding whether it's even installable in your stack. It isn't, in the normal sense: there's no service provider, no config/task.php, and it expects a Symfony kernel, DI container, and console application. composer require glooby/task-bundle inside a Laravel app will pull the code but nothing will boot.

Where to look first, in order:

1. composer.json — check the require block for the Symfony major version and PHP constraint. Given the last release (2019-10-18) you should expect Symfony 3.4/4.x and PHP 7.1–7.3 era constraints. That alone usually blocks installation on a modern Laravel app running PHP 8.2+.
2. DependencyInjection/ and Resources/config/services.yml — this is where the bundle wires up its task registry. Look for a tag name (something like glooby.task or app.task) that marks a service as schedulable.
3. Command/ — find the runner command (typically a task:run-style console command). This is the entry point a single system cron job would call.
4. The task contract — an interface with one method (run(), execute(), or similar). Every unit of work implements it.

The first use case the bundle is designed for is small: define a class that does one thing, tag it as a task in services.yml with a cron expression, add one crontab line that invokes the runner every minute, and let the bundle decide which tasks are due. That's the entire value proposition — schedule-in-code instead of one crontab line per job.

For a Laravel developer the honest mapping is: this is app/Console/Kernel.php::schedule() with Schedule::call() / Schedule::command(), driven by * * * * * php artisan schedule:run. Laravel already ships this. Your "first use case" with this bundle is therefore almost always a reading exercise — study how it structures tasks, then implement the same shape natively. If you genuinely need to evaluate it (e.g. inheriting a Symfony app), spin up a throwaway Symfony 4 skeleton with the matching PHP version and run the runner command by hand before trusting it.

Implementation Patterns

Task-as-service. The bundle's core pattern is one class per unit of work, registered in the container and scheduled declaratively. The task is a plain object with no framework coupling beyond the interface, which makes it trivially unit-testable. In Laravel the direct analogue is an invokable command or a small action class wired into the scheduler:

// config/task-ish equivalent in Laravel
$schedule->call(new PruneStaleCarts)->hourly()->withoutOverlapping();
$schedule->command('reports:daily')->dailyAt('02:15')->onOneServer();

Keep the same discipline: the class does the work, the schedule config decides when. Don't let cron expressions leak into the task itself.

Single-cron-entry topology. The whole model rests on one crontab line hitting a runner every minute. This is the pattern worth stealing regardless of framework — it makes schedule changes a code review instead of a server SSH session, and it survives redeploys. If you're operating a mixed estate (Symfony app + Laravel app on the same box), never let both own the same cron entry. Pick one runner per host.

Registry over inheritance. Tasks are collected via DI tags, not a base class hierarchy. That means adding a job is additive — new class, new tag, done. Anything you build on top should follow that: resolve tasks from the container/config, don't maintain a hardcoded array in a switch statement.

Runner aggregation and exit codes. A good runner iterates due tasks, times each one, captures output, and returns a meaningful exit code. When porting, mirror this: wrap each task in try/catch so one failure doesn't abort the rest of the batch, and log per-task duration. Laravel's Schedule::call() swallows exceptions into logs only if you configure it — be explicit about it.

Cross-boundary integration. If you must keep a Symfony app's scheduled work alive while modernising, the least-bad bridge is Illuminate\Process / Symfony\Component\Process invoked from Laravel's scheduler:

$schedule->exec('cd /srv/legacy && php bin/console app:tasks:run')
         ->everyMinute()
         ->withoutOverlapping();

That gives you one scheduler of record and a clean cut-over point when each legacy task is rewritten as a Laravel command.

Gotchas and Tips

It is effectively abandoned. Last release October 2019, 30 stars, zero dependents. No Symfony 5/6 support, no PHP 8 compatibility work, no security response. Treat it as a reference implementation, not a dependency. Do not put it in a new project.

No Laravel integration, and not a small gap. There's no service provider, no facade, no config publishing, and the DI tag mechanism relies on Symfony's compiler passes. You cannot shim this in with a few lines — you'd be reimplementing the bundle, at which point use Laravel's scheduler.

Cron expression parsing is a dependency-era trap. Bundles of this vintage typically lean on mtdowling/cron-expression, which was renamed to dragonmantank/cron-expression (the version Laravel uses). Watch for abandoned transitive dependencies and expression semantics differences (@daily, L, # handling vary).

Overlap and concurrency. Verify whether the runner takes a lock. Most 2019-era task runners did not, which means a slow task plus a per-minute cron equals stacked processes. In Laravel, always pair long jobs with withoutOverlapping() and onOneServer() if you run more than one node.

Timezone and DST. Schedule expressions are meaningless without an explicit timezone. Check if the bundle supports per-task timezones; if not, "daily at 02:30" silently skips or double-fires on DST boundaries. Laravel's ->timezone('Europe/London') is per-task and worth using.

Config caching bites on Symfony too. If the schedule lives in YAML, cache:clear after edits is mandatory — the same class of bug as Laravel's config:cache making you think a change didn't take.

Debugging strategy. Because the runner decides what's due internally, "my task didn't run" has three causes: not tagged in the container, expression not matching the current minute, or the runner crashing before it reaches your task. Dump the registered task list first (a debug:container --tag=<tag> in Symfony), then test the expression in isolation, then run the runner with verbose output.

Extension points worth copying. The tag-based registry and the "task returns a result object" convention are both good design. If you need real operational visibility in Laravel, spatie/laravel-schedule-monitor gives you the equivalent of the runner's health reporting — including the "did the cron actually fire" alert that this bundle never had.

Bottom line: score of ~2.4 with an opportunity score near 9 reflects the gap — the idea is underserved in some ecosystems, but the implementation is stale, unused, and framework-locked. Leverage it by reading it for twenty minutes and then writing idiomatic Laravel scheduler code.