Partisan: artisan for Laravel packages

One of our favorite things about building in a Laravel app is how much of the boilerplate simply isn't yours to write. php artisan make:model Invoice -mf and you have a model, a migration, and a factory — named right, namespaced right, in the right folders. The make: suite is a huge part of why Laravel feels fast.

We build Laravel and Filament packages at Packstub, and we wanted that exact feeling inside a package directory: type one command, get files in src/ under the package's namespace. So we built it — on top of the excellent tooling the Orchestra team already ships — and we're releasing it free and open source today.

composer require --dev packstub/partisan

vendor/bin/partisan make:model Invoice
# → src/Models/Invoice.php — namespace Acme\Widget\Models;

That's Partisan: artisan for Laravel packages.

Standing on very good shoulders

Package development in Laravel already has great bones, and they come from Orchestra:

• Testbench boots a full skeleton Laravel application around your package — it's how virtually every Laravel package runs its tests, and its CLI gives you serve, migrate, tinker, and a Workbench demo app.
• Canvas is the generator engine — the same make: commands you know, routed through a pluggable preset that decides where files go and what namespace they get.

If you've published a Laravel package, you're almost certainly using Testbench already. Partisan doesn't replace any of this — it's a thin, careful layer on top that adds the missing piece: a preset that understands your package is the app.

One command, your namespace

Partisan reads your package's composer.json — the PSR-4 autoload map, the dev autoload, the registered providers — and points the entire generator suite at it:

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:test InvoiceTest	tests/Feature/…	Acme\Widget\Tests\Feature
make:filament-resource Invoice	src/Filament/Resources/…	Acme\Widget\Filament\Resources\…

…and the rest of the family: casts, controllers, events, jobs, listeners, mail, middleware, notifications, policies, providers, requests, rules, enums, interfaces, traits, views, components, and more.

Because partisan wraps the Testbench CLI, everything Testbench can do still works — vendor/bin/partisan serve, migrate, route:list, workbench:install, and your package's own commands, all from the same binary. And when you do want to generate into your Workbench demo app instead of the package, the standard presets are one flag away: make:model Demo --preset=workbench.

The Filament resource demo

This is the one that made us grin. Filament v4's resource generator produces a whole cluster of files — the resource, its pages, a schema class, a table class. Inside a package, that's a lot of classes to hand-author.

With partisan, declare your panel provider's discovery paths with app_path() — partisan remaps app_path() to src/, so Filament's generators follow along:

$panel->discoverResources(
    in: app_path('Filament/Resources'),
    for: 'Acme\\Widget\\Filament\\Resources',
)

Then:

vendor/bin/partisan make:filament-resource Invoice --generate

…and the complete resource — pages, schema, table and all — lands in src/Filament/Resources under your namespace, ready to ship in your plugin. If you build Filament plugins, this alone is worth the install.

The details that make it feel native

Generating a file in the right place is the easy 80%. The part we spent our time on is the last 20% — the wiring you'd normally do by hand after the generator runs:

• make:command registers the command for you. It offers to add the new command to your package's service provider — inserting into an existing $this->commands([...]) or a spatie-style ->hasCommands([...]) block, adding the import, never duplicating an entry. No provider block yet? It appends a fresh one to boot().
• make:model --factory wires the factory properly. Package factories famously don't resolve by convention — so partisan points the HasFactory docblock at your Database\Factories namespace and adds a #[UseFactory(InvoiceFactory::class)] attribute. Invoice::factory() just works, with no manual newFactory().
• Generated tests extend your base class. make:test extends your package's own tests/TestCase.php when you have one, falling back to Orchestra\Testbench\TestCase otherwise.
• Your providers are live. Providers listed in extra.laravel.providers are auto-registered in the skeleton app, so your package's own artisan commands show up in vendor/bin/partisan list alongside the generators.

Curious how your package got mapped? vendor/bin/partisan partisan:about prints the whole picture — source path, namespaces, database and view targets, discovered providers.

How it works

There's no magic and very little code, which is exactly how we like it. Testbench boots the skeleton app; Canvas routes every generator through a preset; partisan registers a preset built from your composer.json:

• autoload.psr-4 → source path and root namespace
• autoload-dev.psr-4 → tests path and namespace
• database/ and resources/ → database and view targets
• extra.laravel.providers → auto-registered providers

It honors your testbench.yaml — custom skeleton, extra providers, migrations, seeders — exactly like the Testbench CLI does, so it drops into an existing package with zero configuration. The whole thing is backed by a test suite that generates every supported file type into a disposable fixture package and asserts the paths and namespaces, for both Laravel and Filament generators.

Free, open source, yours

Partisan is MIT-licensed and on Packagist today:

composer require --dev packstub/partisan

The code lives at github.com/packstub/partisan — stars, issues, and PRs are all very welcome, especially reports from packages with unusual layouts. We built it because we needed it for our own Filament plugins, and we'd love to hear what it does (and doesn't yet do) for yours.

And if you've never packaged up that piece of code you keep copying between apps — this is a lovely week to start. composer init, composer require --dev packstub/partisan, and make: away.