- How do I dispatch a Laravel queued job from the command line with mxl/laravel-job?
- Install the package with Composer; auto-discovery registers its service provider and the Artisan command. You then pass a job class name and any payload arguments, and the package resolves the class string and dispatches it through Laravel's existing Bus and Queue contracts, so it behaves like a normal dispatch. Run php artisan list after installing to confirm the exact command signature, and make sure you have shell access to the environment you are targeting.
- How do I install mxl/laravel-job in a Laravel application?
- Require it with Composer and let package auto-discovery register the service provider and command; there is no schema change or migration to run. It may publish an optional config file for defaults such as the queue connection and queue name. Pin the version in composer.json and confirm the Laravel constraint matches your application before rolling it out.
- Which Laravel versions does mxl/laravel-job support?
- The package depends on Laravel's console kernel and queued job serialization, both of which have changed across Laravel 8 through 12, so the supported range is whatever its composer.json constraint and CI matrix actually cover. Check those before committing, and treat a future Laravel major upgrade as a potential fork-or-patch event. The safe pattern is to upgrade in a branch with the package installed and vendor-patch rather than waiting on upstream.
- How do I pass arguments or payloads to a job from the CLI?
- CLI input is limited to scalars and arrays, typically supplied as JSON, so jobs you want to expose must be constructor-simple or wrapped in a dedicated adapter job. Mature codebases often have constructors that take value objects, Eloquent models, DTOs, or tenant context, and those will not map cleanly onto command arguments. Budget for that adapter layer explicitly, and check whether the package offers a resolver or hook for non-scalar values.
- Can I choose the queue connection, queue name, or delay when dispatching?
- The package is designed as a CLI front door to Laravel's dispatcher, and the config file is the likely place to set default connection and queue values. Whether per-invocation delay, priority, batches, and chains are honored is one of the questions to confirm in the README before adoption. If you rely on chained or batched jobs, test that path explicitly rather than assuming parity with in-code dispatch.
- Is mxl/laravel-job safe to use in production?
- A command that instantiates arbitrary classes from a string and enqueues them is powerful by design, so restrict it to trusted operators and keep it out of untrusted CI pipelines or shared bastions without an allowlist. The bigger everyday risk is governance bypass: ad-hoc dispatch skips whatever validation, idempotency keys, tenant scoping, and tracing headers your normal dispatch path enforces. Treat it as developer and ops tooling that lives next to your runbooks, not inside your domain layer.
- Does mxl/laravel-job work with Horizon, Telescope, batches, and chains?
- Because dispatch goes through Laravel's Bus and Queue contracts, jobs should appear in Horizon and Telescope the same way any other dispatched job does, provided your normal tagging is configured. Batch and chain support, however, is unconfirmed and should be verified against the README and a staging test. Confirm it also composes with your queue driver, whether Redis, SQS, or database, and with any custom queue middleware.
- How do I test jobs dispatched through the package's Artisan command?
- Use Laravel's Queue::fake or Bus::fake in a feature test, invoke the Artisan command, and assert the expected job was pushed with the expected payload. That also gives you a cheap way to catch constructor-marshalling problems before they reach staging. Run the same command in staging against a real worker before trusting it in production.
- What are the alternatives to mxl/laravel-job?
- The main alternatives are php artisan tinker for manual dispatch, a bespoke internal Artisan command you write and maintain yourself, one-off scripts, or cron wrappers around existing commands. This package sits in the gap between tinker, which is manual and unscriptable, and a custom command, which carries ongoing maintenance cost. Introduce it as a supplement to those practices rather than a replacement, and retire the SSH-and-tinker habit only after the CLI path has proven itself.
- Is mxl/laravel-job actively maintained, and what if it breaks?
- It has around 66 stars and is effectively a single-maintainer package, so plan to own it rather than depend on upstream responsiveness. Check the last commit date and open-issue activity before adopting, pin the version, and be ready to fork or apply a Composer patch if a Laravel upgrade breaks it. Removal is clean, since there are no tables or backfills, so the exit cost is low if it stops fitting.