- Does spipu/process-bundle work with Laravel?
- No. Despite being distributed on Packagist as a PHP package, spipu/process-bundle is a Symfony bundle built around a DI extension, a configuration tree, console commands and event subscribers. None of that glue transports to Laravel, and wiring Symfony kernel plumbing into a Laravel app is a persistent anti-pattern. The only transferable piece is the underlying symfony/process component, which Laravel already pulls in transitively and which you can call directly with no extra dependency.
- What does spipu/process-bundle actually do?
- It gives Symfony applications structured background process management: configurable process definitions, helpers for starting and supervising long-running jobs, locking to prevent overlapping runs, execution and status tracking, and log capture for process output. In practice it wraps symfony/process and adds lifecycle and monitoring glue on top. It is aimed at launching and reaping child processes from a console or request context.
- How do I install spipu/process-bundle?
- In a Symfony application you install it with Composer and register the bundle in your kernel or bundles.php, then configure your process definitions under the bundle's configuration key. Symfony Flex may handle registration automatically depending on the recipe. There is no Laravel service provider, so there is nothing to auto-discover in a Laravel app.
- Which Symfony and PHP versions does spipu/process-bundle support?
- You must check the composer.json constraints on PHP, symfony/process and any Doctrine packages before assuming compatibility, because Symfony major-version drift will strand the bundle quickly. The repository shows zero dependents, so there is no downstream pressure keeping those constraints current. Verify the declared last-release date against the actual tag history, since it may reflect a misconfigured tag or stale metadata rather than active maintenance.
- How does spipu/process-bundle prevent overlapping process runs?
- Locking is a core feature: it prevents the same defined process from being started twice concurrently, which is the usual failure mode when a long job outlives its schedule interval. This is conceptually the same guarantee Laravel gives you with the withoutOverlapping scheduler modifier or a cache lock. If you are building natively, replicate the lock with Laravel's atomic cache locks rather than adding the bundle.
- How do I track the status of background processes and read their logs?
- The bundle provides execution and status tracking plus logging support for process output, typically backed by an optional persistence layer for process state. In a Laravel app you would instead model this yourself with a processes or jobs table, a status state machine, and a scheduled reconciler command that reaps stale entries. Output can go to Laravel's log channels or a per-execution log file.
- Is spipu/process-bundle safe to run in production?
- Treat it with caution. It has zero stars, zero dependents, a single maintainer and a composite score around 19.5 out of 100, meaning effectively no external scrutiny of code that spawns processes with your application's OS privileges. That blast radius makes an unmaintained dependency in this position a standing security and stability liability. The MIT license is clean, but licensing is the only unambiguously favorable signal here.
- Is spipu/process-bundle actively maintained?
- There is no real evidence of active maintenance: no dependents, one maintainer, and release metadata that should be verified against the tag history before you trust it. Do not treat a recent last-release date as proof of activity until confirmed. If you need it long term, you would be the one on the hook when Symfony or PHP upgrades break it.
- What is the Laravel equivalent of spipu/process-bundle?
- Laravel's queue workers, the scheduler with withoutOverlapping, Horizon for supervised workers, and direct calls to symfony/process cover the same ground without a Symfony dependency. For a like-for-like feature set, the native build is roughly a service provider, a config file, an injectable manager or facade, a processes table with a status state machine, a reconciler command, and signal and exit-code handling. That is a one-to-two sprint job for a mid-level engineer and yields code you own, test and instrument.
- Should I use spipu/process-bundle as a reference implementation instead of a dependency?
- Yes, that is the defensible posture: read, do not require. Clone it, read the service definitions, the process manager and the console commands, then write a one-page capability inventory covering the state model, concurrency limits, restart and backoff behaviour, and log capture. That inventory becomes the requirements list for your Laravel-native implementation. Do not add it to composer.json even as a dev dependency, since reading the source is cheap and the dependency is not.