Batch Bundle Laravel Package

Getting Started

Read this first: vimex/batch-bundle is a Symfony bundle, not a Laravel package. The last release was June 2018, it has a single star and zero dependents, so there is no community to lean on and no Laravel-specific documentation. Before you composer require anything, confirm the package still installs cleanly against your PHP and Symfony/Illuminate versions — a 2018 bundle may pin symfony/* constraints that conflict with modern Laravel (which vendors several Symfony components). Run composer why-not vimex/batch-bundle and composer require --dry-run to see conflicts before committing.

If it installs, the first thing to inspect is the bundle class and its Resources/config/services.* files. That tells you what the bundle actually wires up: typically a batch/job manager, a processor or item-reader abstraction, and event listeners. The Laravel-relevant surface is anything outside the bundle class — plain PHP services you could instantiate yourself. The BatchBundle class and its DI compiler passes are dead weight in Laravel.

Your realistic first use case in a Laravel app is not "install a batch manager" (Laravel has one) but "I have an existing Symfony service from this bundle whose algorithm I want to reuse." Treat it as a library of classes, not a framework extension.

Implementation Patterns

Since there is no ServiceProvider, you have two viable patterns.

1. Instantiate bundle services manually. Read the bundle's service definitions, identify the concrete class behind each service ID, and construct it in a Laravel service provider or a factory. For example, if the bundle exposes a BatchManager that takes a list of Job objects and a logger, register it like:

$this->app->singleton(BatchManager::class, function () {
    return new BatchManager(
        config('batch.handlers'),
        $this->app->make(LoggerInterface::class)
    );
});

Watch for constructor args that are Symfony-specific (EventDispatcherInterface, ContainerInterface). Replace them with Laravel equivalents (Illuminate\Contracts\Events\Dispatcher) only if the signatures line up — more often you will need a thin adapter.

2. Reimplement the pattern natively. For most "batch" needs in Laravel 8+, Bus::batch() already covers fan-out/fan-in with callbacks (then, catch, finally), and LazyCollection::chunk() handles streaming large datasets. If what you actually want from this bundle is "run N jobs, then a completion step," you almost always get a better result from:

Bus::batch($jobs)
    ->then(fn () => $this->markComplete())
    ->catch(fn ($batch, $e) => $this->notify($e))
    ->dispatch();

Integration tips. Keep any bundle-derived services behind an interface you own, so the 2018 code never leaks into your domain. If the bundle provides a "processor" with a process($item) contract, wrap it in a Laravel job so it participates in your queue, retries, and Horizon metrics. Never let the bundle's own dispatcher or container bootstrap run inside a Laravel request — it will assume Symfony's kernel.

Gotchas and Tips

• No auto-discovery. Laravel will not register the bundle. You must wire everything yourself or it simply won't exist at runtime.
• Symfony DI coupling is the real cost. Any service the bundle pulls internally goes through Symfony's container, so you end up reconstructing a mini container by hand. Count the constructor dependencies before you commit — if it is more than two or three, this is a losing battle.
• Abandonment risk. Last release 2018, one star, zero dependents means: no security patches, no PHP 8.x fixes, no maintainer to ask. Vendor it into your own namespace or fork it if you depend on it, and pin the commit.
• Version conflicts. 2018-era bundles often require symfony/console ^3.4|^4.0; modern Laravel ships Symfony 6/7 components. Composer will either refuse to install or force downgrades that break other packages. Check composer why-not output carefully.
• Debugging. Because there is no Laravel integration, exceptions surface as raw PHP errors from deep inside the bundle with Symfony-flavored messages. Log around the entry point you control; do not expect stack traces to point at your app code.
• Extension points are Symfony-shaped (compiler passes, tagged services, event subscribers). In Laravel you would emulate them with your own Event::listen wrappers and a config array, but by the time you have done that you have usually re-implemented the useful 10% of the bundle.
• Strong recommendation: unless a specific algorithm inside this bundle is genuinely hard to reproduce, do not adopt it. Laravel's queue batches, Bus::batch, chunked Eloquent queries, and horizon cover the same ground with active maintenance and a debugging story you actually understand. Reserve this package for the narrow case where you are porting code from a Symfony app and want to lift a specific, self-contained class out of it.