Filament Installer Laravel Package

Technical Evaluation

Architecture fit. awcodes/filament-installer is a build-time Composer plugin that scaffolds a Filament panel provider through interactive CLI prompts. From a TPM lens, that framing matters: it produces no runtime surface, ships nothing to production, and its output (a panel provider plus published config/assets) is indistinguishable from what a developer could hand-write. The architectural ceiling is therefore low — the package is a convenience wrapper, not a component. More critically, its function is now covered first-party by Filament's own filament:install --panels and panel-generation commands. Adopting it means introducing a third-party dependency to duplicate a vendor capability, which is the wrong default in any dependency-governance framework.

Integration feasibility. Feasible only against a narrow, dated matrix. The final release (2022-10-19) sits in the Filament v2 / Laravel 9 window; on modern Filament and Laravel, expect dependency-resolution friction, plugin-API drift, and generated scaffolding that no longer matches current provider-registration conventions. Composer 2.2+ blocks plugins by default, so adoption also carries an allow-plugins governance workstream. For a TPM, the honest read is: high feasibility for a one-off spike, low feasibility as a repeatable path on the current stack.

Technical risk.

• Abandonment: no release in over two years, single maintainer, no documented security-response path.
• No adoption signal: 14 stars and 0 dependents means essentially zero ecosystem validation; breakage will not be surfaced or fixed by anyone else.
• Supply-chain surface: install-time code execution by an unmaintained package requires OSS/security intake and pinning.
• Scaffolding drift: generated providers/config can be structurally stale, producing boot errors or silent divergence from first-party conventions — and bad scaffolding gets committed and copied.
• Non-determinism: interactive prompts are hostile to CI, containers, and reproducible onboarding.
• Reversibility is the saving grace: blast radius is a branch, not a deployment.

Key questions.

1. Does first-party Filament tooling already cover this bootstrap? If yes, what is the residual gap worth paying dependency cost for?
2. What exact Filament major / Laravel / PHP / Composer versions does v2.0.2 declare support for, and are any of those still on our supported matrix?
3. Is this greenfield bootstrap, legacy-stack reproduction, or onboarding enablement — and which team owns the outcome?
4. Can it run non-interactively and deterministically, or is it developer-machine-only?
5. Has it cleared OSS intake, including Composer plugin execution and allow-plugins policy?
6. Who owns the generated provider after day one, and what is the exit plan when (not if) the package breaks resolution?
7. Is the time saved (roughly 10–30 minutes per project) material at our project volume, or is it rounding error?

Recommendation for evaluation: treat as reject for standard adoption; permit as a disposable spike. Harvest the scaffolding pattern, not the plugin.

Integration Approach

Stack fit. Only aligns with Laravel applications on Filament v2-era dependencies. It does not fit a current Filament baseline, a monorepo, a service-template pipeline, or any environment where provisioning must be automated. It also does not fit an existing Filament app — the panel provider already exists, so there is nothing to integrate.

Migration path. There is no migration to this package; it is itself a bootstrap step, and a superseded one. The defensible sequence:

1. Confirm whether the first-party Filament installer satisfies the need — this closes the evaluation most of the time.
2. If a legacy stack genuinely requires the old output, run the installer on a throwaway branch in an isolated environment and capture the generated diff.
3. Diff that output against current first-party scaffolding to quantify how stale it is.
4. Fold the useful parts into an internally owned starter template or scaffold command.
5. Do not carry awcodes/filament-installer as a persistent require-dev entry.

Compatibility. Pin an explicit matrix — PHP, Laravel major, Filament major, Composer version — and read the package's own composer.json constraints rather than inferring them from the README. Verify allow-plugins behavior in the target Composer version before promising a smooth install. If any constraint conflicts, stop; do not paper over it with --ignore-platform-reqs or relaxed constraints in a shared repo.

Sequencing (delivery view).

1. Need confirmation — sponsor sign-off that first-party tooling does not close the gap.
2. Version gate — go/no-go against the 2022 constraint set.
3. Intake — OSS/security review plus maintainer-risk assessment; Composer plugin execution explicitly in scope.
4. Timeboxed spike — one developer, one branch, fixed hours, capture artifacts.
5. Output comparison — provider registration, config publishing, asset publishing, panel discovery versus first-party.
6. Decision memo — adopt-pinned (rare), template-adapt (likely), or discard (default).
7. Institutionalize — if the pattern is worth keeping, encode it in a maintained internal template with tests, owned by platform.

Operational Impact

Maintenance. Effectively zero upstream maintenance since October 2022. Any adoption transfers full maintenance to us: compatibility patches, Composer plugin API updates, and fixes for Filament convention changes. Pin the exact version and treat it as frozen code with no expectation of upstream support.

Support. No vendor, no commercial backing, single maintainer, negligible community footprint. There is no informal support channel and no ecosystem pressure to keep it working. If used at all, it needs a named internal owner and a runbook entry — otherwise it becomes orphaned infrastructure nobody is accountable for.

Scaling. No runtime or production scaling implications. Operational scaling is about repos, teams, and environment parity: interactive prompts and machine-dependent behavior disqualify it from CI, container builds, and automated service creation. Past a handful of developers or repos, a deterministic internal template is both cheaper and safer than an interactive third-party plugin.

Failure modes.

• Composer blocks the plugin via allow-plugins, producing inconsistent installs across developer machines.
• Dependency resolution conflicts on current Laravel/Filament/Composer.
• Prompt hangs or divergent answers in non-interactive contexts.
• Outdated generated provider causing runtime boot errors or silent divergence from documented setup.
• Published config/assets going stale relative to the installed Filament version.
• Supply-chain exposure from install-time execution of unmaintained code.
• Developer-to-developer drift because scaffolding lives in muscle memory rather than a reviewed, version-controlled template.

Ramp-up. Technically trivial — a Filament developer can run it in minutes. The real cost is governance ramp-up: teaching the team the Composer plugin allow-list policy, maintaining a version matrix, and normalizing "spike, capture, discard" as the sanctioned pattern. Budget effort for intake and diff review, not for learning the tool.

TPM bottom line. The question is not whether we can integrate this — we can, cheaply. It is whether we should own an unmaintained duplicate of a first-party capability in exchange for a few minutes saved per project. The answer is no. Use it, if at all, as a reference design for our own scaffold, and keep the dependency out of the portfolio.