Filament Plugin Tools Laravel Package

Technical Evaluation

Architecture fit. This is developer tooling, not a runtime dependency. It scaffolds Filament plugin skeletons — service providers, config, assets, stubs, directory layout — so it belongs in require-dev and never enters the request path. For a TPM the consequence is straightforward: no latency exposure, no customer-facing blast radius, and failures surface in a developer's branch or CI rather than in production. That places it in the discretionary DevEx/tooling budget line, not the tier that needs architecture review or a change advisory.

Integration feasibility. High and cheap to falsify. Adoption is a composer require --dev plus possibly publishing stubs; there is no data model, no migration, no coupling to application runtime beyond Filament's own panel registration. One engineer can validate end-to-end in a spike branch inside a day, and reversibility is a single composer remove --dev. That asymmetry — cheap to try, cheap to undo — is exactly the profile where a time-boxed decision beats a committee decision.

Technical risk. Three items for the risk register, ordered by how much they threaten the decision:

1. No external evidence base. Four stars and zero dependents means we would be an early adopter; problems would be ours to discover. This does not disqualify the package for dev tooling, but it does mean the pilot must be a real plugin with real surface area, not a hello-world that proves only that the generator runs.
2. Release provenance. The 2.0.5 changelog compares 3.0.0...2.0.5 — a 2.0.5 tag published against a 3.0.0 baseline. Either the compare link is mistargeted or a version line has moved backwards. Both readings indicate loose release hygiene, and both damage our ability to reason about what we would pin in a shared template. This is a gate on standardization, not a footnote.
3. Transitive dependency removal. The substance of 2.0.5 is dropping illuminate/contracts. Filament almost certainly supplies Contracts transitively, so real-world impact is likely small — but any consumer that relied on this package to pull Contracts into the graph can now hit Class not found. It is the classic change that passes on the maintainer's machine and fails on a consumer's, and a reminder that dependency posture here can shift between patch releases.

Key questions.

• Is 2.x an actively maintained line (a Filament v3 backport) while 3.x targets Filament v4? Which line are we standardizing on, and for how long? Nothing we decide is durable until this is answered.
• What does composer.json declare for require vs require-dev, and what is the PHP/Laravel/Filament constraint matrix per line? If the package leaks test-only or dev-only deps into require, we would end up publishing plugins that carry unnecessary weight.
• Was illuminate/contracts removed because it was genuinely unused, or to dodge a conflict with a specific Laravel release? The first is hygiene; the second means the removal may regress.
• Do the generators emit tests and a CI-friendly structure by default, or only production scaffolding? Our leverage calculation changes if the generated skeleton includes a working test harness.
• Who is the maintainer, what is the observed release cadence over the last 12 months, and is there a readable tagged diff rather than only a compare link?

Integration Approach

Stack fit. Appropriate for a Laravel 10/11/12 team on Filament v3 with an actual or imminent plugin surface — three or more in-house Filament plugins, or a roadmap that implies them. Below that threshold the scaffolding savings do not repay the extra abstraction and the additional convention layer in code review. It is a poor fit for a single monolithic admin panel with no plugin strategy; there the tooling is unused ceremony that still has to be upgraded.

Migration path. None required — this is an additive greenfield dev dependency, not a replacement for existing infrastructure. The only migration-shaped concern is aligning its supported Filament major with ours. The related organizational decision is where generated plugins live: scaffolding into a packages/ directory wired through a Composer path repository lets teams iterate without tagging releases, and it is the correct default for a pilot because it keeps the feedback loop fast and defers release engineering until the pattern has proven itself.

Compatibility. Two axes must be written down rather than assumed:

• Filament major. Pin the version matching our panel version explicitly. Do not float ^ on a package whose 2.x/3.x relationship is undocumented — a float here means an unreviewed major jump can land in a routine composer update.
• Illuminate surface. After installing on a clean tree, confirm no in-house code or plugin depends on Contracts arriving transitively. composer why illuminate/contracts on a scratch install settles this in minutes and should be a checklist item, not an investigation.

Sequencing.

1. Spike (1–2 days). Fresh Laravel at our version plus our Filament version, require --dev, run every generator end-to-end, and time the output against our current manual setup.
2. Dependency audit. Confirm Contracts resolution post-install and no conflict against our existing lockfile.
3. Pilot on one real, non-critical internal plugin. Extract an existing Filament resource/page set rather than generating a toy; the value only shows up on realistic surface area, and this is the step that tells us whether the generated skeleton survives contact with our conventions.
4. Decision gate. Standardize only if the spike shows measurable setup-time savings and the maintainer clarifies the 2.x/3.x line. Otherwise fall back to a thin internal template repo — the switching cost in that direction is a day, not a quarter.

Do not adopt 2.0.5 as a blanket team standard before step 4. Standardizing on a line whose cadence we cannot predict is how a cheap dev dependency quietly becomes a recurring tax.

Operational Impact

Maintenance. Low-to-moderate, and concentrated in upgrades rather than steady state. The package is small and its surface is developer-facing, so day-to-day cost is near zero. The burden to budget is the periodic Filament major bump, which will likely require a matching package major plus regeneration of our scaffolding templates. The critical governance rule: generated code is owned by the consuming team, not by the package. If that boundary is not stated explicitly in the adoption doc, every upgrade becomes a merge exercise across every plugin we have ever generated.

Support. Single-maintainer community OSS, MIT, no commercial backstop and no SLA. Acceptable for a dev dependency; unacceptable anywhere in the runtime path — and the discipline of stating that boundary is itself valuable, because it stops a tooling convenience from being quietly promoted into shared infrastructure. The mitigation to record is not a support contract but a fork plan: the package is small enough that forking is a genuine low-cost option if the maintainer goes quiet. A TPM should document that option up front, with a named owner, so it is not negotiated during a crisis.

Scaling. Effectively unlimited technically — it is exercised per developer, not per request, so panel count and traffic do not move the cost curve. The real scaling risk is organizational: the value of a shared skeleton grows with the number of plugins and teams, but so does the coordination cost of changing the convention later. Once five plugins are generated from a template, changing that template is a small migration program rather than an edit. That argues for finalizing the skeleton conventions deliberately during the pilot — service provider shape, config naming, asset compilation, test placement — rather than letting them accrete, because the cheap moment to decide is before the second team adopts it.

Failure modes. Four to plan for, none production-severity: (1) silent staleness — plugins generated early diverge from later conventions until the shared standard no longer describes the estate, mitigated by a short review checklist and a dated template version in each plugin's README; (2) unpinned major drift — a composer update pulls an incompatible package major into dev environments, mitigated by exact pins in the root require-dev; (3) transitive dependency assumption — code that compiled via Contracts arriving through this package stops resolving after a patch release, mitigated by the clean-install audit and CI on a locked tree; (4) maintainer abandonment — no upstream fixes for a future Filament major, mitigated by the pre-agreed fork plan and the fact that generated output remains functional independent of the tool. Note the reassuring property: because generated code is owned by the consumer, losing the package degrades onboarding speed, not existing plugins.

Ramp-up. Under a day for an engineer already fluent in Filament — the package adds conventions, not a new programming model. Budget the real ramp-up cost for reviewers and onboarding docs, not for the tool itself: someone has to write down the pinning policy, the "generated code is ours" rule, and the directory convention, or each team will invent its own. That documentation is a half-day of TPM-owned work and is the difference between a shared standard and a shared suggestion.