Worker Bundle Laravel Package

Getting Started

First, the reality check: weblabel/worker-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/worker.php. It is designed to be registered in a Symfony kernel via config/bundles.php and configured through Symfony's DI extension system. A Laravel developer evaluating this should treat it as "a library of PHP classes you may be able to borrow from," not something you composer require and php artisan vendor:publish.

If you are in a Symfony codebase (or a Laravel app that already embeds Symfony components):

1. composer require weblabel/worker-bundle — verify the PHP and Symfony version constraints in composer.json before committing; with 0 stars and 0 dependents, the version matrix is likely narrow.
2. Register the bundle in config/bundles.php:

   return [
       // ...
       Weblabel\WorkerBundle\WeblabelWorkerBundle::class => ['all' => true],
   ];
   

3. Run bin/console config:dump-reference weblabel_worker to discover the actual configuration tree. The extension alias is almost certainly weblabel_worker (Symfony convention derives it from the bundle name), but confirm rather than assume — this is the single fastest way to understand what the bundle actually does.
4. Run bin/console list and look for commands prefixed with the bundle's namespace. A worker bundle almost always ships a worker:run, worker:consume, or similar long-running command.

Where to look first in the repo: DependencyInjection/ (tells you the config schema and available services), then Command/ (tells you the actual entry points), then composer.json (tells you whether this is even installable on your stack). Skip the README until you've seen the DI extension — for a 0-star bundle, the code is more trustworthy than the docs.

First use case: pick the simplest job your app has (sending an email, generating a thumbnail) and wire it through the bundle end-to-end in a scratch branch. You want to know within an hour whether the bundle's model of "a worker" matches yours before you build anything real on it.

Implementation Patterns

Service-tagging pattern. Symfony worker bundles typically discover work via tagged services (e.g. kernel.event_listener or a custom weblabel_worker.job tag). If that's the case here, your job handlers are plain services — no base class inheritance required, which makes them unit-testable in isolation:

# config/services.yaml
App\Worker\SendInvoiceEmail:
    tags: ['weblabel_worker.job']

Run under a process manager, never in a terminal. Long-running consumers should be supervised (Supervisor, systemd, or Symfony's own messenger:consume if the bundle delegates to Messenger). Give the process a restart policy and rotate logs — you will not be watching it.

Dispatch from the request cycle, consume out-of-band. The healthy pattern is: controller writes an intent (DB row, queue message, whatever the bundle's transport is) and returns immediately; a separate worker process drains it. If the bundle encourages synchronous execution inside the HTTP request, that is a design smell for anything slow.

Laravel-side integration. If you are trying to use this from Laravel, the only realistic patterns are:

• Port the idea, not the code. Read the bundle's worker loop and reimplement it on top of illuminate/queue + php artisan queue:work. You get first-class Horizon, retries, and failed-job handling for free.
• Bridge via a shared transport. If the bundle speaks a standard protocol (AMQP, Redis, DB polling), let it consume from the same queue Laravel pushes to. Both sides talk to the broker; neither knows about the other.

Testing. Register jobs as services and call their handle/__invoke methods directly in tests. Reserve end-to-end worker tests for a single smoke test — spinning up the real worker loop in CI is slow and flaky.

Gotchas and Tips

• Bundle ≠ package. There is no WeblabelWorkerServiceProvider. Do not spend an afternoon looking for one; there isn't one, and there won't be.
• Zero stars / zero dependents is a real signal. Not disqualifying for MIT code, but it means: no community to answer questions, no guarantee of a fix when Symfony 8 lands, and no third-party blog posts to debug against. Budget time to read the source. Vendor-pin the exact version.
• Configuration alias mismatch. The extension alias is derived from the bundle class name, which does not always equal the Composer package name. If config:dump-reference weblabel_worker fails, try variations or grep getAlias() in DependencyInjection/.
• Long-running processes leak. Workers accumulate memory (Doctrine identity map, Eloquent models, closures). Use the bundle's --limit/--max-jobs/--time-limit option if it exists; if it doesn't, wrap the command in a supervisor config with stopwaitsecs and periodic restarts.
• Database connections go stale. MySQL drops idle connections after wait_timeout (default 8h). Long workers will throw "server has gone away." Reconnect on failure or restart workers more often than the timeout.
• Handle signals. A worker that ignores SIGTERM gets SIGKILLed mid-job. Look for pcntl_signal handling in the command; if it's absent, that job can be interrupted at an arbitrary point and you must make handlers idempotent.
• Retries and dead-lettering are your job. Do not assume the bundle has them. Log failures with enough context to replay manually.
• Extension points will be tagged services and event dispatchers. Before forking the bundle to change behaviour, check whether a compiler pass or a decorating service gets you there — decorating is cheaper to maintain than a fork.
• Debug flags. Set APP_DEBUG=0 and a dedicated log channel for workers. Debug-mode container rebuilds on every job will destroy throughput.