Filament Installer Laravel Package

Product Decisions This Supports

• Build vs. buy vs. use first-party — and the answer is usually "first-party." The decision this package actually informs isn't "adopt this installer" but "how do we provision Filament admin panels?" Filament ships php artisan filament:install --panels, which covers the same ground and is versioned with the framework. Any evaluation here is a comparison against upstream, not against building our own tool. Default to the first-party path and require an explicit gap before considering this package.
• Onboarding time-to-first-resource. The measurable benefit is collapsing "require Filament → publish config → generate a panel provider → register it" into one interactive prompt. That's a one-time 10–30 minute saving per project, not a recurring one. It's only a real product lever if we spin up many Filament projects — starter kits, agency scaffolding, internal golden-path templates, workshop/demo environments.
• Internal scaffolding roadmap. If we maintain a Laravel/Filament starter template, this repo is more valuable as a reference design than as a dependency: interactive prompts, provider generation, sensible color/icon defaults, asset publishing. The decision is whether to copy the pattern into our own generator, not whether to require it.
• Dependency governance / procurement review. Fourteen stars, zero dependents, no release since October 2022, single maintainer — these are concrete abandonment-risk inputs for an "approved dependencies" conversation, and they belong on the record even if the outcome is an easy no.
• Use cases where it might still earn a slot. Pinned reproduction of a legacy Filament v2 setup, disposable demos/hackathons, or training material where "one command, answer prompts" beats "follow the docs." All dev-time, all low blast radius.

When to Consider This Package

Consider it only when all of the following are true:

• You are scaffolding Filament v2-era panels and need to reproduce that exact install sequence — the last release (v2.0.2, Oct 2022) predates Filament's current first-party installer and targets that older stack.
• You've read the package's own composer.json and confirmed its Laravel/PHP/Composer constraints against your pinned versions, rather than assuming compatibility.
• You're willing to pin the exact version and vendor or fork it. Treat it as a snippet library with a CLI, not a supported dependency.
• The setup is developer-machine, interactive, one-off — not CI, not Docker, not automated service creation.
• The time saved is worth the governance cost of an unmaintained Composer plugin (which requires explicit allow-plugins consent on Composer 2.2+).

Look elsewhere when:

• You're starting any new project on current Filament. Use php artisan filament:install --panels. Everything this package does is upstream's job now.
• You need support, security patching, or upgrade guarantees. Single maintainer, no releases in two-plus years, no downstream dependents means no ecosystem pressure to fix breakage.
• Your provisioning runs non-interactively. An interactive CLI is the wrong shape for CI or containers; use an idempotent command or a committed starter template.
• You already have a working panel provider. There is nothing to retrofit — this is a bootstrap tool, not a migration tool.

Practical gate: spend an hour in a throwaway repo, diff the generated provider and config against first-party output, then decide to (a) pin and use it, (b) copy the generated files into our starter template, or (c) discard it. Option (b) captures nearly all the value.

How to Pitch It (Stakeholders)

For executives: This is a small developer-experience utility — an installer that saves a few minutes setting up a Filament admin panel in a Laravel app. It is not platform infrastructure, it has no runtime footprint, and it requires no budget. Its function is now covered by Filament's own install command, and its adoption signals are negligible (14 stars, no dependent packages, no release since October 2022). Recommendation: do not add it to our dependency portfolio. No roadmap impact. At most it informs an internal starter template we control.

For engineering leads: Low risk to try, moderate risk to keep. It's a thin, likely-abandoned wrapper around steps a single artisan command plus minor manual edits already covers, and it's a Composer plugin — install-time code execution from an unmaintained source, which means it goes through intake and gets pinned if used at all. The cheapest safe play: run it once on a disposable branch, capture the generated panel provider and config, and drop the dependency. That preserves the onboarding benefit — a predictable, one-command panel bootstrap — without inheriting maintenance ownership of someone else's abandoned package.

For the team: On a legacy Filament v2 codebase, this can save real setup time — pin v2.0.2, vendor it, and name an owner. On any current Filament version, ignore it and use the first-party installer. Don't merge generated scaffolding you haven't diffed against current conventions; bad scaffolding propagates quietly across repos.