xammie/make-commands
xammie/make-commands adds extra Artisan generators to Laravel so you can scaffold common PHP classes—actions, services, DTOs, and more—with customizable stubs. It keeps new files consistent and saves boilerplate typing during development.
composer require xammie/make-commands --dev. This is a code-generation tool — it has no runtime role in production.php artisan vendor:publish --tag=make-commands-config, which gives you config/make.php. Publish the stubs too (--tag=make-commands-stubs) so you own the templates rather than reaching into vendor/.config/make.php is the whole API surface: each entry registers an Artisan command name and maps it to a stub file, a target namespace, and a target path. Read that file first, then skim vendor/xammie/make-commands/src for the base generator class to see which placeholders ({{ class }}, {{ namespace }}, {{ rootNamespace }}, etc.) get substituted and which flags (--force) are inherited from Laravel's GeneratorCommand.make:action pointing at App\Actions / app/Actions with an action.stub, run php artisan make:action CreateOrder, and confirm the generated class has the right namespace, imports, and parent. If it does, you have a repeatable template for every other artifact type in your app.^0.4, that constraint will block installation on Laravel 10 projects; bump to ^0.5. Laravel 10 requires PHP 8.1+, so confirm your CI matrix.make:action, make:service) keep them discoverable under php artisan list make.vendor. Publish, then edit and commit stubs/*.stub. This is the highest-leverage move: it turns the package into your team's boilerplate standard, and stub diffs show up in code review like any other change.make:billing-action → app/Modules/Billing/Actions) when you run a modular monolith, instead of hand-editing namespaces after generation.make:* calls in a single custom Artisan command (make:feature) to scaffold a vertical slice — action + DTO + test — in one shot. This is where day-to-day time savings actually compound.$this->artisan('make:action', ['name' => 'Foo'])->assertSuccessful() plus assertFileExists() catches broken stubs after a refactor. Iterate over every entry in config('make.commands') so a new addition is automatically covered.vendor/bin/pint --dirty to a pre-commit hook or a composer generate script so generated files land already conforming to style.config/make.php, run php artisan config:clear. A cached config silently ignores new entries, which reads as "the package is broken."make:controller or make:model shadows Laravel's built-in. Always verify with php artisan list make after adding an entry.{{.class_exists after require) catches this.assertFileExists/path assertions in tests.--force overwrites without prompting. Fine interactively, dangerous in wrapper commands and CI. Never expose it unguarded in a make:feature composite.composer install --no-dev the package disappears but previously discovered manifest entries can linger; run php artisan package:discover when switching between dev and prod installs. Don't reference package classes at runtime (e.g. unconditionally in a service provider) or production boots will fail.^0.5, and read release notes on each bump — v0.5.0 itself is a compatible Laravel 10 addition, but the 0.x line offers no formal BC guarantee.buildClass() / getReplacements() — that is the standard hook for injecting imports, interfaces, or attributes into generated classes. Prefer this over string-hacking the config.-vvv; a missing or unreadable stub usually surfaces as a bare file_get_contents error with no path context, so check the resolved stub path against the published location first.How can I help you explore Laravel packages today?