Filament Installer Laravel Package

Getting Started

Reality check first. awcodes/filament-installer last shipped v2.0.2 in October 2022 — that's Filament v2 / Laravel 9 territory. Before you composer require anything, open the repo's composer.json on the v2.0.2 tag and read the require block. If your app is on Filament v3+, stop: run php artisan filament:install --panels and move on. The installer only pays for itself on a legacy Filament v2 app or when you are deliberately rebuilding an old stack for a demo or training repo.

Where to look, in order:

1. README.md — the invocation command. Is it composer create-project awcodes/…, a composer require + artisan wrapper, or a standalone binary? This determines whether the installer runs automatically or on demand.
2. composer.json — look for "type": "composer-plugin" and the extra.class entry. That pinpoints which Composer event fires the prompts (almost always post-create-project-cmd). This is the single most important line in the package; it dictates whether "just install it" quietly launches an interactive wizard.
3. The generated artifacts — typically app/Providers/Filament/AdminPanelProvider.php plus a config/filament.php entry. Read these before you accept the prompt answers, because you'll own them, not the package.

Install with Composer 2.2+ (plugins are blocked by default):

composer require awcodes/filament-installer --dev
# Composer halts:
#   Do you trust "awcodes/filament-installer" to execute code and wish to enable it now?
# Answer "n" the first time so you can inspect the plugin class before granting trust.

# Then explicitly allow it in composer.json:

"config": {
    "allow-plugins": {
        "awcodes/filament-installer": true
    }
}

First use case — the one worth doing. Spin up a throwaway repo pinned to Filament v2, run the installer, and diff the output against the first-party scaffolding. That diff is the real deliverable. Copy the generated panel provider into your internal starter template and drop the dependency. This gives you the "one-command panel bootstrap" onboarding benefit without keeping a four-year-dormant package on your require-dev list.

After the wizard, verify three things before you commit anything:

• app/Providers/Filament/AdminPanelProvider.php (or whatever path it chose) exists and is registered in config/app.php or via package discovery — the installer claims to auto-register, but confirm.
• The panel ID, path, and auth guard in the generated provider match what you answered.
• php artisan route:list | grep admin shows the panel routes, and the panel loads at its path in a browser.

If any of those fail, delete the generated file and start over — don't patch around the installer's mistakes.

Implementation Patterns

Pattern 1: The disposable spike. The most honest way to use this package day-to-day is not as a dependency. Create a scratch branch, composer require it, run the wizard, capture the generated files, then composer remove it and commit only the generated provider. You get a reproducible starting point without carrying an unmaintained plugin into every future Composer resolution.

git checkout -b bootstrap/spike
composer require awcodes/filament-installer --dev
php artisan vendor:publish --provider="Awcodes\\FilamentInstaller\\..." # or composer create-project, per README
# answer prompts, capture diffs
git add app/Providers/Filament/
git checkout main
git merge bootstrap/spike -- app/Providers/Filament/   # cherry-pick the artifact only
composer remove awcodes/filament-installer --dev

Pattern 2: Interactive prompt as a scaffolding interview. The installer's actual value is that it asks good questions — panel ID, path, auth, colors, icon. Steal that prompt sequence as a design reference for your own make:panel-style command. A ten-line $this->ask() / $this->choice() block that mirrors it costs less than a Composer plugin and lets you keep the questions in sync with your team's conventions.

// Your internal command, inspired by the installer's flow
$id   = $this->ask('Panel ID', 'admin');
$path = $this->ask('Panel path', $id);
$auth = $this->choice('Auth guard', ['web', 'admin'], 0);
$this->callSilently('filament:install', ['--panels' => true]);
// then rewrite the generated provider with $id/$path/$auth

Pattern 3: Golden-path starter repo. If you run many Filament apps, don't run this installer per project. Run it once against a clean Filament v2 scaffold, commit the result as a skeleton branch, and have new projects composer create-project your-org/filament-skeleton. This is exactly the pattern the package's assessment notes point to: encode the output in a maintained template, not a third-party plugin.

Pattern 4: CI/Docker — don't. Interactive prompts are hostile to non-deterministic environments. If you must provision Filament non-interactively, use first-party artisan commands with flags, or commit the provider. There is no documented non-interactive mode for this package, so treat it as a developer-machine-only tool and never wire it into a Dockerfile or CI job.

Integration tips for a legacy v2 app:

• Pin exactly: "awcodes/filament-installer": "2.0.2" in require-dev.
• Add it to your allow-plugins config once, review it in code review, and document why it's there.
• If it emits a config/filament.php block, diff it against Filament v2's published config — the installer may be pinning stale defaults.
• Run it in a fresh clone before letting teammates run it, so you can spot the prompt hang risk early.

Gotchas and Tips

The plugin fires on install, not just on demand. Because it's a Composer plugin registered to a post-install event, composer require in a fresh clone of a repo that already lists it will re-prompt every time. Teammates will get confused when composer install starts asking about panel IDs. Always pair require-dev installs with allow-plugins documented in the repo's README and a note that the prompts are expected.

Composer plugin trust is per-machine for a reason. If a teammate answers "n" to the allow-plugins prompt, their composer install will silently skip the plugin and the panel won't be generated for them — leading to "works on my machine" bootstrap drift. The fix is to commit allow-plugins to composer.json, but that also means anyone cloning the repo auto-approves an unmaintained install-time script. For a 14-star package, that's a real supply-chain decision — run it past whoever owns your dependency policy.

Generated code drifts from current Filament conventions. The 2022-era output may use provider APIs, middleware names, or route registration patterns that have moved on. Compare the generated AdminPanelProvider against vendor/filament/filament/stubs/ in your actual install — if the shape is wrong, fix it manually before committing, because the difference will bite you at the next filament:upgrade.

Debugging a silent wizard. If the interactive flow hangs in a terminal multiplexer or through a php artisan tinker shell, run it in a plain terminal. If it finishes but nothing's generated, check php artisan vendor:publish --list to see if the provider was registered at all — a composer install without allow-plugins is the usual culprit.

Config extension points are limited by design. The package publishes a fixed set of files. Anything it doesn't ask about (multi-tenancy, custom middleware, discovery paths) you'll add by hand. Treat the generated provider as a starting point, not a contract — edit it freely, because the package won't overwrite it after the first run.

Exit plan, written down. Before you merge anything, write a one-liner in the PR: "This dependency exists only for initial scaffolding; the generated provider lives at X; delete this package on Y date." At 14 stars and no downstream dependents, nobody else is going to keep it working, so your future self needs to know it was a one-shot decision and not an ongoing commitment. The cheapest safe move is: run it once, capture the output, remove the dependency.