Interactive Make Laravel Package

Getting Started

Install (dev only). This is scaffolding tooling — it has no runtime role, so keep it out of production autoload:

composer require --dev laracademy/interactive-make

On Laravel 5.5+ the service provider is auto-discovered. On older skeletons, register it manually in config/app.php:

Laracademy\InteractiveMake\InteractiveMakeServiceProvider::class,

Where to look first. Run php artisan list make and confirm the make:interactive command appears. Then check config/interactive-make.php (publish it if it isn't there) — that file controls output paths, namespaces, and which artifacts the wizard is allowed to chain together. If you only read one thing before using the package, read that config.

First use case. Scaffold a single CRUD-ish resource in one pass instead of five separate make: calls:

php artisan make:interactive

Walk the prompts: choose the artifact type (model / migration / controller / seeder / request, depending on your version), give it a name like Post, then declare fields one at a time with their types. The payoff is that the migration, model, and controller are generated consistently from one description of the entity, rather than you retyping column names three times and drifting.

Verify with:

git status          # see exactly what landed
php artisan migrate --pretend

Then commit as a single "scaffold Post" commit so the generated baseline is easy to review and easy to revert.

Implementation Patterns

Wizard-first, hand-edit-second. Treat the wizard as a boilerplate generator, not a code generator. A good rhythm is: run the wizard for the shape of the resource (table, model, controller skeleton), commit that, then immediately hand-write validation, authorization, relationships, and business logic. Reviewing a pure-boilerplate diff is fast; reviewing boilerplate mixed with hand-written logic is not.

Use it for the boring middle, not the edges. The wizard earns its keep on entities with 4–10 plain scalar columns (a Ticket, a Product, an Announcement). It does not earn its keep on join tables, polymorphic relations, or anything with a composite key — you'll spend more time fixing the output than writing it.

Keep the interactive run local and serial. Because it writes several files per invocation, run it on a clean working tree so git diff is unambiguous. Don't run two wizard sessions in parallel in the same repo; the prompts are sequential and it's easy to lose track of which entity you're midway through.

Wrap it for repeatability. If your team scaffolds often, add a Composer script so nobody forgets the --dev context:

"scripts": {
    "scaffold": ["@php artisan make:interactive"]
}

Pair with native commands for the rest. The wizard won't cover everything. After it runs, fill gaps with the standard generators (make:request, make:policy, make:test, make:factory) so naming stays consistent with what the wizard produced.

Stub customization is the real extension point. If the package exposes publishable stubs/views, publish them and adjust the generated controller to your house style (e.g. form requests instead of inline $request->validate, resource routes instead of explicit ones). That turns a one-off convenience into a team convention — one edit to the stub, every future scaffold matches.

Docker / Sail users: prompts need a TTY. Use docker compose run --rm -it app php artisan make:interactive (or sail artisan make:interactive), not a detached exec, or the wizard will hang or bail immediately.

Gotchas and Tips

The maintenance question is the headline. Last release was May 2020 — Laravel 7 era. On modern Laravel (9/10/11) and PHP 8.1+, expect possible friction: Symfony Console's question-helper signatures and return types have tightened over that window, and generated code may use idioms that are now discouraged (e.g. $table->bigInteger('x')->unsigned() instead of foreignId()->constrained()). Test on a throwaway branch before adopting, and be prepared to pin or vendor it. If it errors on boot, that's a signal to walk away rather than patch a dev tool.

Interactive commands don't belong in CI. Any pipeline step that hits this command will either hang waiting on stdin or fail outright. Keep it strictly a human-driven local tool.

Config changes need a cache clear. Because output paths and namespaces live in config, php artisan config:clear after editing — otherwise you'll generate into the wrong directory and not notice until the autoloader can't find the class.

File overwrites. The wizard will typically ask before clobbering an existing file. Read the confirmation carefully — answering yes on a model you've already customized is a silent, unrecoverable-in-the-moment loss (recoverable only via git, which is why the clean-tree habit above matters).

Field declarations are the fragile part. Column type names, nullability, and defaults depend on the version's accepted syntax. If a field is silently dropped, that's the first place to look — generate to a scratch branch and --pretend the migration to confirm the column actually exists before building on it. Foreign keys and indexes are almost always a manual follow-up in the migration.

Reserved words bite. A field named order, group, or key will produce a migration that fails or needs quoting. Rename in the wizard prompt rather than patching the migration afterward.

Debugging: run with -vvv to surface the underlying exception, since the wizard's own prompt layer tends to swallow stack traces behind a friendly message. If a prompt loops, Ctrl+C and inspect the config — a malformed path or namespace is the usual culprit.

Have an exit ramp. Give the package a short trial. If it's fighting you, the native equivalents cover 80% of the value with zero maintenance risk:

php artisan make:model Post -mfsc   # model, migration, factory, seeder, controller

For anything beyond that, Laravel Blueprint (YAML-defined drafts) is the better-maintained successor to this style of workflow. Treat laracademy/interactive-make as a productivity nicety for greenfield scaffolding, not a dependency your team's workflow is built on.