Artify Laravel Package

Getting Started

Install as a dev-time scaffolder (its commands generate code, they don't run in production):

composer require sectheater/artify --dev

If you want to tweak stubs or default namespaces, publish the package config (provider/tag name varies slightly between versions — run php artisan vendor:publish and pick the Artify entry, or use --tag=artify if available). Then clear caches:

php artisan config:clear
php artisan list | grep artify   # confirm command registration

Look here first, in this order:

1. php artisan artify — the interactive hub. It lists every generator (controller, model, request, resource, migration, etc.) and lets you pick one, name it, and choose companion files. This is the fastest way to see what the package actually offers in your installed version.
2. config/artify.php — namespaces, output paths, and stub locations. If your app uses App\Models or a modular structure, this is the file you'll edit.
3. vendor/sectheater/artify/src/Stubs/ — the templates every command renders. Read one before you trust the output.

First real use case: scaffold an API endpoint end-to-end.

php artisan artify:controller PostController --api --model=Post --request --resource

Then wire it up and confirm the pieces landed where you expect:

Route::apiResource('posts', PostController::class);

If the generated imports point at App\Post but your model lives in App\Models\Post, fix the config before generating more files — otherwise you'll be hand-correcting every scaffold.

Implementation Patterns

Use the hub for discovery, the per-command form for repetition. php artisan artify is great for a first look at options and for one-off exploration. For anything you'll do more than twice (new feature, new module, team onboarding), drop to the explicit commands so the invocation is copy-pasteable, reviewable in a PR description, and scriptable.

Scaffold the whole vertical slice in one call. The main value over make:* is generating the model + migration + controller + form request + resource together with matching names and imports. Adopt a house convention and encode it in the command line you paste into your team's scaffolding doc:

# Web controller with validation + resource
php artisan artify:controller InvoiceController --model=Invoice --request --resource

# API-only controller
php artisan artify:controller InvoiceController --api --model=Invoice --request

Generate the model and migration together, then edit. Let Artify produce the model, migration, and factory in one pass, then immediately fill in $fillable, casts, relationships, and column definitions. Treat the generator as a "correct file skeleton" step, not a "correct domain code" step.

Standardize with custom stubs. Copy vendor/sectheater/artify/src/Stubs/* into resources/stubs/artify/ (or stubs/artify/), edit them to match your team's style — strict types, final classes, docblocks, your base controller, your resource shape — and point the config at that directory. This is the single highest-leverage thing you can do with the package: every future scaffold comes out already conforming, so code review stops arguing about boilerplate.

Pair with make:* for the gaps. Artify doesn't cover everything in a modern Laravel app (policies, events/listeners, jobs, casts, enum-backed columns). Keep php artisan make:policy in the same workflow so the generated slice is complete.

Compose with your route file and tests. After scaffolding, immediately add the route entry and a feature test stub in the same commit. A scaffold that exists but isn't routed or tested tends to rot in a branch.

Respect existing structure. If your app is modular (app/Domain/Billing/...), change the configured namespaces/paths once and generate into the module rather than moving files afterwards. Moving generated files by hand is where imports and namespaces break.

Gotchas and Tips

Version drift is the big one. The last release is April 2020, which puts it in the Laravel 5.8–7 era. On Laravel 8+ you should expect friction:

• Generated model factories may use the old $factory / factory() style instead of newFactory() and HasFactory.
• Model namespace assumptions default to App\ — Laravel 8's App\Models\ convention means imports will be wrong until you fix the config.
• PHP 8 syntax, attributes, and typed properties won't appear in stubs (usually harmless, but compare output before committing).
• Service provider auto-discovery generally still works, but verify with php artisan list — a silently failing provider is the most common "the package is broken" report.

Treat Artify as a convenience for a legacy-leaning codebase; test a scaffold in a scratch branch before rolling it into a Laravel 10/11 app.

Interactive prompts hang CI. php artisan artify and any command that asks for input will block in a pipeline or a git hook. In automation, always use the fully-specified per-command form with flags, or skip Artify entirely.

Publishing stubs is not optional if you edit them. Anything under vendor/ is wiped by composer update. Publish or copy the stubs first, update the config path, and commit them.

Config changes need a cache clear. php artisan config:cache in production/staging will freeze your artify.php values. After editing paths or namespaces run php artisan config:clear before regenerating, or you'll get files in the old location and wonder why.

Overwrite behavior. Generators typically refuse to clobber existing files unless forced. That's good — but when regenerating after a stub change, you must consciously delete or --force the target. Prefer git diff over trusting the flag; a forced regeneration can silently replace hand edits.

composer dump-autoload after generating into new directories. If you scaffold into a namespace path Composer doesn't know about yet, class-not-found errors are autoload-related, not package-related.

Debugging a bad scaffold: run the command with -vvv, then open the corresponding command class in vendor/sectheater/artify/src/Commands/ and read which stub it renders and which variables it substitutes. Nearly every "wrong output" issue is either (a) wrong stub being used because of config, or (b) a variable the stub expects but the command didn't populate for your flag combination.

Extension points, in order of cost: custom stubs via config → overriding the config paths/namespaces → extending a command class and re-registering it → forking. Reach for the fork only if you need Laravel 10/11 output; at that point, weigh Artify against php artisan make:* plus a small internal generator of your own, since the upstream is dormant.