- What is ashallendesign/laravel-executor used for?
- It lets you define install and update deployment tasks as executor classes instead of ad-hoc shell scripts. Each executor can run shell commands, PHP closures, and Artisan commands in sequence, and Artisan commands let you list and run your executors. Typical uses include seeding reference data, creating a first admin user, publishing assets, warming caches, and generating keys. It sits alongside Laravel's migration system rather than replacing it.
- Does laravel-executor support Laravel 10 or Laravel 11?
- The last release was December 2020, which places it in the Laravel 8 and PHP 7.4 to 8.0 window. Nothing in the release history suggests it was validated against Laravel 9, 10, or 11, which changed service provider signatures, console command registration, and PHP minimums. Running it on a modern app realistically means forking it, bumping the composer.json constraints, and running the test suite yourself. Check the repository for newer releases before deciding.
- How do I install ashallendesign/laravel-executor?
- Require it with Composer, publish its config file, generate an executor class, and register the steps you want to run. The integration effort is small, so the blocker is currency rather than complexity. On a current Laravel app you would likely need to fork and update the framework constraints first.
- Do executor steps run on every deploy or only once?
- The package distinguishes install and update lifecycle hooks, so the intent is different work at first install versus later releases. The exact idempotency contract, whether once ever, once per version, or every deploy, should be verified in the source before you trust it in production. Whatever mechanism records completed executors becomes a ledger you have to manage like a schema.
- Where does laravel-executor store which executors have already run?
- That depends on the implementation, since state is typically held in a database table or the cache. Cache-backed state is a serious hazard across multi-node deploys, where each server may see a different cache. Confirm the storage mechanism and treat it as a de facto schema you cannot change without its own migration story.
- Is laravel-executor safe for concurrent deploys to multiple app servers?
- There is no ecosystem evidence of production validation, and with zero dependents there are no reported regressions to learn from. Concurrent execution against the same database or cache is exactly the scenario where a small latent bug produces a half-initialized environment rather than a failed page render. Serialize your deploys, or prefer an in-house command with explicit locking.
- Is ashallendesign/laravel-executor still maintained?
- The last release is December 2020 and the package has no dependents, so treat it as effectively unmaintained. It is MIT licensed and small enough to read in an afternoon, which lowers the intellectual risk but not the operational risk of running unreviewed code on the install and update path. There is no active security disclosure process. Check the maintainer's responsiveness first, because a fork would become your ongoing ownership cost.
- What are alternatives to laravel-executor?
- Most teams are served by php artisan migrate --force plus db:seed, or by a single in-house Artisan command backed by a deployed_tasks table of roughly 100 to 200 lines. That gives you full ownership with no version-constraint risk. Forking the package or copying the pattern into your own app are the other realistic options.
- Should I use laravel-executor instead of migrations and seeders?
- It is adjacent to, not inside, the migration system, so you end up with two parallel what-has-already-run ledgers unless you deliberately unify them. For a standard CRUD app, migrate --force and db:seed already cover the need and the package only adds a concept. It fits best for genuinely multi-phase installs such as SaaS tenant bootstrap or marketplaces with large reference data.
- How do I test laravel-executor executor classes?
- There is no sign the suite was run against modern framework versions, so you would be writing the compatibility tests yourself. Keep executors small and side-effect-explicit so they can be invoked directly in a test, and assert on the Artisan and shell calls they make. In a forked copy, run the existing tests under PHP 8.2 and your target Laravel version before wiring it into a deploy script.