Filament Plugin Cli Laravel Package

Technical Evaluation

Architecture fit. filament-plugin-cli is a Composer-installed Laravel CLI tool that scaffolds Filament plugin boilerplate — service providers, config, migrations, and asset/asset-registration wiring. It sits entirely in the development/build-time layer: it is a require-dev dependency invoked by a developer or CI job, produces source files that are committed to the repo, and has zero runtime footprint in production. That is an architecturally clean profile — it cannot affect request handling, container bindings, or deployment artifacts. Fit is strong if our roadmap includes authoring or vendoring Filament plugins; if we only consume third-party Filament plugins, the package is irrelevant.

Integration feasibility. Straightforward mechanically (composer require --dev, then invoke the command), but gated on an undocumented compatibility matrix. We must confirm: which Filament major versions the generated stubs target (v3 vs v4 scaffolding conventions differ materially), PHP version floor, and Laravel version constraints. A scaffolding tool that emits code for the wrong Filament major is worse than no tool, because the mismatch surfaces only after the generated files are reviewed and committed.

Technical risk. Two releases in this window (v0.0.17 → v0.0.19) contain two separate fixes to the same regex used for "tag removal." That is the single most important signal in these notes. Regex-driven mutation of existing files — stripping or rewriting marker tags inside provider/config/bootstrap files — is brittle by construction, and two consecutive patches to the same expression is evidence the logic is still being converged on, not stabilized. Combined with the 0.0.x version line (pre-1.0, no API stability guarantee) and what appears to be a single-maintainer project, this warrants treating the tool as experimental. The style-only change to the configuration message is cosmetic and carries no risk.

Key questions.

• What exactly does "tag removal" mutate — composer.json, bootstrap/providers.php, Filament panel provider panel() calls, or in-file markers? Can we see the diff before it is applied?
• Is the command idempotent, and does it fail atomically or leave half-written files on error?
• Which Filament and Laravel majors are declared as supported, and is that verified in the package's CI matrix?
• Is there a documented stub-customization path, or are templates hardcoded (i.e., will we fork the package to change conventions)?
• What is the maintainer bus factor and release cadence? No security policy or disclosure channel was referenced.

Integration Approach

Stack fit. Appropriate for a Laravel + Filament codebase where we intend to build first-party plugins. Adopt as a developer-workstation and scaffolding convenience only — never as a production dependency, never invoked during deploy.

Migration path. There is nothing to migrate: the package installs no runtime code, publishes no config consumed at boot, and registers no service provider behavior that persists. Adoption cost is a composer.json dev entry; removal cost is composer remove --dev plus a check that it did not leave generated artifacts behind. This is a reversible, low-commitment trial.

Compatibility. Pin an exact version (e.g. "asciito/filament-plugin-cli": "0.0.19") rather than a caret range — on a 0.0.x line a caret constraint is effectively >=0.0.19 <0.0.20 under Composer semantics, but an explicit pin removes ambiguity and keeps the regex-behavior change from arriving silently. Verify the generated output against our installed Filament major before accepting any scaffold.

Sequencing.

1. Spike (half a day): install in a throwaway branch, generate a plugin, hand-review every produced file, and git diff against a manually scaffolded equivalent.
2. Verify the fix: specifically exercise the tag-removal path — regenerate over an existing plugin directory to confirm re-runs do not corrupt provider or config files, since that is what v0.0.19 changed.
3. Gate on review: if output passes review, adopt with a documented "review every generated file" rule; if not, keep the manual scaffold template.
4. Do not wire it into CI codegen until the project reaches 1.0 or the stubs stabilize across several releases.

Operational Impact

Maintenance. Near-zero ongoing runtime maintenance, but a nonzero ownership transfer: everything the tool generates becomes our code, maintained by us. The package's defects do not persist at runtime; they persist as committed source. Budget a review step on every scaffold, permanently.

Support. No commercial backing and no visible support channel. Upstream bug turnaround is unknown; given two regex patches in quick succession, we should assume we may need to pin a known-good version and patch locally. Forking is cheap here because the package is build-time only.

Scaling. Irrelevant as a runtime scaling concern — the tool executes per-developer, not per-request. The scaling question is team-wide consistency: whether ten engineers generate ten structurally different plugins. Mitigate by capturing one reviewed reference plugin as our internal template and treating the CLI as a starting point rather than an authority.

Failure modes.

• Silent file corruption: a regex over- or under-matching during tag removal, leaving a malformed provider or composer.json. Detectable via review + php -l + composer validate; the two v0.0.19 fixes target exactly this class.
• Partial generation: command fails mid-run leaving a half-scaffolded plugin. Mitigate by always running in a clean git working tree so git checkout is a complete rollback.
• Stale templates: stubs lag the installed Filament major, producing deprecated or non-functional scaffolding. Mitigate with a compatibility check at adoption and a re-check on Filament upgrades.
• Supply chain: a pre-1.0, small-maintainer dev dependency executes code on developer machines with filesystem write access. Constrain via pinned version and lockfile review.

Ramp-up. Very low — an artisan-style command, minutes for a developer already fluent in Filament. The real ramp-up cost is institutional: establishing the review discipline and the "reference plugin" pattern before multiple engineers generate divergent scaffolds in parallel.

Verdict. v0.0.19 is a maintenance patch, not a capability release — two brittleness fixes plus a cosmetic message change. It does not change the recommendation, because there is no prior assessment to change: this is an initial entry. Recommendation is Trial, scoped to a single spike with exact version pinning and mandatory output review; promote to Adopt only after the stubs hold stable across several releases and Filament-version support is documented.