Laravel Turbomaker Laravel Package

Getting Started

This release turns the adapter from a stub into a real bridge: ModelSchemaGenerationAdapter::generateAll() now delegates to the underlying GenerationService and produces actual output.

1. Install in lockstep. The adapter requires grazulex/laravel-modelschema:^1.3.1. Do not let Composer resolve 1.3.0 — that version reports generation success incorrectly, which masks failures the adapter now depends on detecting.

   composer require grazulex/laravel-modelschema:^1.3.1
   

2. Publish config (vendor:publish for the package's config tag) and confirm the adapter is bound in the container — either via the package's service provider or your own explicit binding if you've overridden it.
3. Look first at the adapter class itself (ModelSchemaGenerationAdapter) and the GenerationService it now calls. Prior to v2.5.1 the adapter returned simulated results, so any internal docs, examples, or blog posts describing a no-op generateAll() are stale.
4. First use case: point the adapter at a single model schema definition and generate the model + migration + factory on a throwaway branch. Diff the output before committing — this is the first release where that output is real rather than a placeholder.

use Illuminate\Support\Facades\App;

$adapter = App::make(ModelSchemaGenerationAdapter::class);
$result  = $adapter->generateAll();

// $result now reflects actual generated fragments, not a simulated payload.

Implementation Patterns

Wrap generation in an Artisan command. Day-to-day you don't call the adapter from a controller; you call it from a command so it's scriptable and CI-friendly.

class GenerateFromSchemaCommand extends Command
{
    protected $signature = 'schema:generate {--model=}';

    public function handle(ModelSchemaGenerationAdapter $adapter): int
    {
        $result = $adapter->generateAll();

        $this->info("Fragments: {$result->fragmentCount()}");

        return self::SUCCESS;
    }
}

Treat generateAll() as fail-fast. The new behaviour throws when a generator returns no fragments. That is the intended contract — let it bubble up in CI, catch it only where you want to degrade gracefully (e.g. an optional generator that legitimately produces nothing for a given schema).

Segment generators by responsibility. Because a single empty generator now fails the whole run, keep custom generators narrow and make their supports()-style guard explicit. A generator that silently matches nothing is the most common cause of a failed batch.

Regenerate in a sandbox branch. Generated code is diffed, not trusted. A typical workflow: run the command, git diff, review, then commit. This matters more now that output is genuine.

Testing pattern. Swap in a fake/stub generator that returns a deterministic fragment set, and assert on the aggregated fragments rather than on filesystem writes. Reserve one integration test that hits the real GenerationService against a fixture schema to catch upstream contract drift.

Version-gated behaviour. If you support both pre- and post-2.5.1 in different branches of your app, guard any assertions about generation output behind a version check — the semantics differ fundamentally.

Gotchas and Tips

• Upgrading from earlier 2.5.x will break tests, not production code. Anything asserting on the old simulated generateAll() payload is now asserting against real fragments. Expect failures in adapter tests and fix the expectations, not the adapter.
• "Generator returned no fragments" is usually a wiring problem, not a schema problem. Check, in order: the generator is registered in config, its guard/supports() method actually matches your schema, and the schema definition reached the generator (dump the resolved schema if unsure).
• The ^1.3.1 floor is load-bearing. On 1.3.0, success reporting is wrong, so a real generation failure can look like a pass. Pin it and let Dependabot/Renovate bump within the constraint, not below it.
• Debugging tip: log the generator class names that ran alongside the fragment count per generator. Since a zero-fragment generator aborts the run, the last logged name is almost always the culprit.
• Empty is not the same as absent. A generator that intentionally produces nothing for a given model still trips the new failure. If that's legitimate for your domain, have it emit an explicit "no-op" fragment or filter it out before the aggregate check.
• Extension point: subclass the adapter if you need pre/post hooks around generateAll() (e.g. formatting generated PHP with Pint, or writing fragments somewhere other than the default destination). Prefer composition — inject a decorator — over forking the package.
• Don't mix generated and hand-edited files blindly. Establish a convention early (generated files marked with a header comment, or a dedicated namespace) so regeneration doesn't clobber customisations. This becomes urgent now that output is real.