Laravel Generator Laravel Package

Getting Started

This is a tiny, archived (last release May 2022, zero stars, zero dependents) scaffolding package whose purpose is narrow: read a JSON description and emit Eloquent models and "action" classes. Treat it as a code-generation utility you vendor into one project, not as infrastructure you depend on across many.

First steps, in order:

1. Read the source before the README. With zero dependents there is no blog post, no StackOverflow trail, no issue history worth relying on. composer require hitocean/laravel-generator, then open vendor/hitocean/laravel-generator/src and find (a) the service provider, (b) anything under Console/. The command signature there is the real documentation.
2. Check the service provider's registration style. A 2022 package may use $this->app->bind/singleton in register() and load commands manually in boot() rather than commands(). If commands don't appear in php artisan list, that's the first thing to fix (see Gotchas).
3. Check composer.json constraints. If it pins illuminate/support: ^8.0|^9.0, install it in a scratch Laravel 9 app first and confirm the generator runs before you put it near a production codebase. Do not attempt to install it into a Laravel 11/12 app and expect php artisan to boot cleanly.
4. Write one hand-made JSON spec and generate into a throwaway namespace. Point the output at app/Generated/ (or whatever the package's config/stub exposes) rather than app/Models/ for the first run, so you can diff the output without polluting your domain.

First real use case: you have a domain area (say Billing) described in a spreadsheet or a client spec, and you need 8–15 models with corresponding single-purpose action classes. Instead of hand-writing them, you transcribe the spec once to JSON, run the generator, and get consistent skeletons — fillable arrays, casts, and invokable action classes — that you then flesh out. The value is entirely in the first 20 minutes of each feature, not in ongoing codegen.

Implementation Patterns

Spec-in-repo, generate-once. The package's implicit model is "generate, then own the code." Commit the JSON spec under something like database/schemas/ or specs/ for provenance, but do not wire the generator into CI. Regenerating over hand-edited models is where these tools bite; keep the spec as a record of intent, and let the generated PHP drift into being normal application code.

Contract-first scaffolding for a new bounded context. Author the JSON as the contract (field names, types, relations, action names), run the generator into a fresh namespace, then immediately move the files into your real app/Models and app/Actions namespaces with a git mv and a namespace rewrite, or run the generator with the target path already correct if it supports a path argument. Doing it in one pass avoids the "generated models live in a weird namespace" cleanup later.

Action classes as the seam. The most useful half of this package is the action generation — one invokable class per use case gives you a testable unit that's trivially mockable and keeps controllers thin. Pattern:

// generated skeleton, then filled in
final class CreateInvoice
{
    public function __invoke(CreateInvoiceData $data): Invoice
    {
        // transaction, domain rules, events
    }
}

Generate the shells, then inject your existing form-request/DTO layer into __invoke rather than letting the generator's constructor signature stand — those signatures are the least trustworthy part of a 2022 codegen output.

Round-trip into your own Artisan command. If you decide the JSON format is genuinely useful, the durable move is to consume the package once to learn the shape of its output, then write a thin php artisan make:domain-from-spec command in your app that reads the same JSON and calls artisan make:model / make:class under the hood. You keep the speed, you lose the abandoned dependency, and you control the stubs. This is the recommended end state for anything you'll use more than twice.

Pair with migrations and factories you generate yourself. Assume the package does not emit migrations or factories (verify). Run it for models and actions only, and keep schema authoring in php artisan make:migration / make:factory so your database layer has a single, conventional source of truth.

Integration tip: normalize JSON types before generation. Whatever the package's type mapping is, feed it conservative values (string, integer, boolean, datetime) and handle decimal, json, enum, and money types by hand-editing the generated $casts. This is faster than debugging the mapper.

Gotchas and Tips

• Archived means no fixes. Pin the exact version in composer.json ("hitocean/laravel-generator": "1.x" style, not ^), because there will be no patch release if a transitive constraint breaks. Better: commit composer.lock and add a note in your README that the package is frozen.
• No dependents = no validated Laravel version matrix. The listed support range is aspirational. Verify php artisan still boots after install; a stale service provider that calls $this->commands([...]) from register() or references a removed Str helper will fail at container boot or on first invocation.
• Commands may not be auto-discovered. If php artisan list doesn't show a generator command, register it manually in AppServiceProvider::boot(): $this->commands([\Hitocean\Generator\Console\...::class]);. Find the class name in the package's src/Console.
• Overwrite behaviour is undefined and version-specific. Before pointing it at real directories, run it twice against a scratch path and diff. If it silently overwrites, never run it against a directory containing hand-edited files — set up a git status checkpoint as a habit.
• Naming and pluralization assumptions. Codegen packages of this era often hardcode Str::plural, Str::studly, and a Models sub-namespace. Snake-case JSON keys with acronyms or non-English words will produce mangled class names; normalize keys in the spec rather than patching stubs.
• Relations. Expect only the simplest belongsTo/hasMany emission, if any. Polymorphic, pivot with extra columns, and self-referential relations will almost certainly need manual work — don't design a schema around the generator's limits.
• fillable vs guarded. Generated models may come out with $guarded = [] or a full $fillable including id/timestamps. Review every generated model for mass-assignment exposure before merging, especially if the JSON was authored by someone else.
• JSON parsing edge cases. Unknown keys and missing keys are likely to fail loudly with a bare exception. Wrap the first few runs in a try/catch or run with -vvv to get the stack trace; the error messages are unlikely to name the offending field.
• Extension points are stubs, not interfaces. Check for a stubs/ or config/generator.php published via vendor:publish. If stubs are plain .stub files, editing them in your app is the cleanest way to bend output to your conventions — but do it in a published copy, never in vendor/.
• Don't let it near production paths on autopilot. The realistic failure mode with an abandoned, untested generator is a half-written model that passes composer dump-autoload and fails at runtime. Generate, review the diff, run your test suite, commit — in that order, every time.
• Exit strategy. Budget the migration to your own in-app command from the moment you adopt this. Given zero stars, zero dependents, and a two-year-old last release, the package's only real value is the idea and the JSON format; the code itself is a temporary convenience.