A complete Laravel API with clean architecture in 30 seconds, tests included

I counted the files I create every time I add a resource to a Laravel API. Model, migration, controller, a form request, a resource, a factory, a seeder, a policy. If the project cares about architecture, add a DTO and a service class. Then the tests.

Twelve files before the first line of actual business logic. I got tired of typing them, so I wrote a generator. It's MIT, I maintain it solo, and v3.6 shipped this week.

One command

composer require --dev nameless/laravel-api-generator



php artisan make:fullapi Post --fields="title:string,content:text,status:enum(draft,published),published_at:datetime"

Output:

app/

├── DTO/PostDTO.php

├── Enums/Status.php

├── Http/

│   ├── Controllers/PostController.php

│   ├── Requests/PostRequest.php

│   └── Resources/PostResource.php

├── Models/Post.php

├── Policies/PostPolicy.php

└── Services/PostService.php

database/

├── factories/PostFactory.php

├── migrations/xxxx_create_posts_table.php

└── seeders/PostSeeder.php

tests/

├── Feature/PostControllerTest.php

└── Unit/PostServiceTest.php

routes/api.php  ← apiResource registered

[GIF demo.gif (voir fichier 12) : vraie exécution en terminal, pas Claude Design]

The VS Code extension: same engine, no terminal needed

[VISUEL 11 (fichier 13) : VRAI screenshot de l'extension VS Code, habillé ensuite dans Claude Design]

If you'd rather click than type, the free

The part I actually care about: the architecture

Plenty of tools can spit out a model and a migration. What I wanted was the layering I end up building by hand on every serious project. The generated controller is thin:

public function store(PostRequest $request)

{

    $dto = PostDTO::fromRequest($request);

    $post = $this->service->create($dto);



    return new PostResource($post);

}

Validation lives in the form request, business logic in PostService, and data crosses layers as a typed readonly PostDTO. When the project grows, the place where new logic should go already exists. That's the whole point.

Models your IDE can read

Each generated model comes with a real PHPDoc block:

/**

 * @property int $id

 * @property string $title

 * @property string $content

 * @property Status $status

 * @property \Illuminate\Support\Carbon|null $published_at

 * @property-read \Illuminate\Database\Eloquent\Collection<int, Comment> $comments

 */

class Post extends Model

So $post->title autocompletes in VS Code and PhpStorm without installing ide-helper. The generator already knows every field and relation at generation time; writing the docblock costs it nothing.

What enum(draft,published) produced

That one field definition created five coherent pieces:

• 
  App\Enums\Status, a native backed enum


• the cast on the model


• 
  Rule::enum(Status::class) in both form requests


• 
  fake()->randomElement(Status::cases()) in the factory


• 
  $table->enum('status', [...]) in the migration

Before v3.6 the package just mapped enums to strings. Wiring the whole chain took longer than I expected, mostly because of the factory.

The tests are written, not scaffolded

This was my line in the sand. Most generators leave you empty test classes. Here php artisan test is green right after generation: index, store, validation errors, update, delete are all covered with real assertions.

it('creates a post', function () {

    $payload = Post::factory()->raw();



    $this->postJson('/api/posts', $payload)

        ->assertCreated();



    $this->assertDatabaseHas('posts', ['title' => $payload['title']]);

});

That's the Pest style, from the --pest flag. Without it you get PHPUnit classes with the same coverage.

Docs, Postman, auth

--postman writes a ready-to-import collection at the project root. The controllers are written so

If you try it and something breaks, open an issue. Schema edge cases reported by users have driven most of the recent releases, and I'd rather hear about yours than guess.