# Generators

Partisan routes the entire `make:` family through a generator preset built from your package's `composer.json`, so every command produces files inside your package with your namespace.

## Where files land

For a package named `acme/widget` with `"Acme\\Widget\\": "src/"`:

| Command | Destination | Namespace |
| --- | --- | --- |
| `make:model Invoice` | `src/Models/Invoice.php` | `Acme\Widget\Models` |
| `make:command SyncInvoices` | `src/Console/SyncInvoices.php` | `Acme\Widget\Console` |
| `make:migration create_invoices_table` | `database/migrations/…` | — |
| `make:factory InvoiceFactory` | `database/factories/…` | `Acme\Widget\Database\Factories` |
| `make:seeder InvoiceSeeder` | `database/seeders/…` | `Acme\Widget\Database\Seeders` |
| `make:test InvoiceTest` | `tests/Feature/…` | `Acme\Widget\Tests\Feature` |
| `make:filament-resource Invoice` | `src/Filament/Resources/…` | `Acme\Widget\Filament\Resources\…` |

…and the rest of the suite: casts, controllers, events, jobs, listeners, mail, middleware, notifications, policies, providers, requests, rules, views, components, enums, interfaces, traits, and more. Filament generators are covered in detail in [Filament plugins](https://packstub.dev/docs/partisan/filament-plugins).

## The wiring you'd normally do by hand

Generating the file is the easy part; partisan also takes care of the follow-up edits:

### `make:command` registers the command

After generating, partisan offers to register the new command in your package's service provider (automatic under `--no-interaction`; opt out with `--no-register`). It inserts into an existing `$this->commands([...])` or a spatie-style `->hasCommands([...])` block — adding the import, never duplicating an entry — and appends a fresh `$this->commands([...])` block to `boot()` when the provider has neither.

### `make:model --factory` wires the factory

Package factories don't resolve by Laravel's app conventions, so partisan wires them explicitly: the `HasFactory` docblock points at your `Database\Factories` namespace and a `#[UseFactory(InvoiceFactory::class)]` attribute is added to the model. `Invoice::factory()` resolves at runtime with no manual `newFactory()` method. If a future Laravel stub ships its own factory wiring, partisan detects it and only corrects the namespace.

### `make:test` extends your base test case

Generated feature tests extend your package's own `tests/TestCase.php` when you have one, or `Orchestra\Testbench\TestCase` otherwise.

### `make:provider` stays hands-off

The class is written into `src/Providers`; registering it in your package's provider chain is deliberately left to you — provider wiring is structural enough that you'll want it explicit.

## Generating into the Workbench app instead

The standard Canvas presets remain available per command when you want a file in your Workbench demo app rather than the package itself:

```bash
vendor/bin/partisan make:model Demo --preset=workbench
```

## Beyond generators

Because partisan wraps the Testbench CLI, everything Testbench can do works from the same binary — `vendor/bin/partisan serve`, `migrate`, `route:list`, `workbench:install`, and your package's own artisan commands (auto-registered from `extra.laravel.providers` — see [Configuration](https://packstub.dev/docs/partisan/configuration)).