- Can I use pyrowman/pheanstalk-bundle in a Laravel application?
- Only partially. The package is a Symfony bundle, meaning its value is a Bundle class, a DependencyInjection extension, a Configuration tree, and compiler passes, none of which Laravel's package discovery loads. In a Laravel app you would effectively be installing it to reach the underlying Pheanstalk client and then wiring that client into the container yourself. Treat it as a beanstalkd transport with a Symfony-shaped packaging layer, not as a Laravel package.
- Does this bundle provide a Laravel queue driver for beanstalkd?
- No. There is no Illuminate queue connector, queue implementation, or job class in this package, and Laravel has no first-party beanstalkd driver. To use it as a queue backend you must write a BeanstalkdConnector implementing ConnectorInterface, a Queue subclass handling push and pop, and a Job subclass implementing release, delete, touch, and bury semantics. That is real, bounded engineering work rather than a composer require.
- How do I install pyrowman/pheanstalk-bundle and check what dependencies it pulls in?
- Run composer require pyrowman/pheanstalk-bundle in a throwaway branch first, then immediately inspect the resolved dependency tree with composer why symfony/framework-bundle and composer show --tree. The critical question is whether symfony/framework-bundle is a hard require or only a dev or suggest dependency, because pulling an entire foreign framework into a Laravel service is close to disqualifying. Timebox this to a short spike and record the dependency graph before committing to anything.
- How do I configure a beanstalkd connection in config/queue.php using Pheanstalk?
- There is no bundle-provided config for Laravel, so you build it yourself: add a beanstalkd entry to config/queue.php with host, port, and timeout, and bind a configured Pheanstalk instance as a singleton in a service provider. Mirror the semantics from the bundle's Symfony Configuration class rather than copying its YAML structure. Keep credentials and host values in environment variables so queue workers and web producers share one source of truth.
- Which Laravel and PHP versions does pheanstalk-bundle support?
- This is unverified from the available information, since the package's composer.json constraints are not documented in the release notes. PHP 8.2 and 8.3 compatibility therefore needs to be confirmed by actually resolving the package in your target environment. The package is also Symfony-oriented, so Laravel version support is largely a function of whether its symfony/* constraints collide with the framework versions you already run.
- What changed in version 1.0.0 and is it a breaking change?
- The 1.0.0 release notes are only links to a closed milestone and a project board, with no changelog, breaking-change disclosure, or upgrade guide. For a 0.x to 1.0.0 promotion that is the biggest unknown: it could be a stability declaration over an unchanged API, or a genuine breaking reset. Diff the tags or read the commit history before assuming either.
- How do I test a Pheanstalk and beanstalkd integration in Laravel?
- Run beanstalkd in a local container and prove a single put, reserve, and delete round trip against it before writing any adapter code. Once you have a connector, test the job lifecycle explicitly: release with delay, bury, touch, and delete, plus worker timeout behaviour. Because beanstalkd is a real daemon, prefer integration tests for the transport and fakes or an in-memory queue for application-level feature tests.
- Can I use the Pheanstalk client standalone without Symfony?
- In principle yes, since Pheanstalk itself is a pure-PHP beanstalkd client with no Symfony requirement. The practical constraint is whether this bundle declares symfony/framework-bundle as a hard dependency, in which case Composer will still install it. If that happens, require the pda/pheanstalk client directly instead and skip the bundle entirely.
- What are the alternatives to this bundle for beanstalkd queues in Laravel?
- You can depend on the Pheanstalk client alone and hand-write a connector, which keeps the dependency graph small and avoids Symfony contracts. The other option is not using beanstalkd at all and staying on Laravel's Redis or SQS drivers, which are first-party and already operated in most estates. Adopt beanstalkd only if you specifically need its job semantics, and be ready to justify running a new stateful daemon.
- Is pyrowman/pheanstalk-bundle production-ready and actively maintained?
- It is risky on the evidence available. The namespace is single-author, so bus factor is the dominant long-term concern, and 1.0.0 is the first stable tag with essentially no production-hardening record in the wild. The upstream Pheanstalk library is mature but low-velocity. Pin the version, vendor the client if possible, and keep a documented exit path back to Redis or SQS.