Filament Package Standard Laravel Package

Technical Evaluation

Architecture fit. This is not a runtime library — it is a development standard and scaffolding/tooling contract for packages built on the filament-package-template v2 architecture. It sits entirely in require-dev and governs repository shape (.editorconfig, stubs, Workbench, assets), CI (PHPUnit/Pest strictness, Larastan, Zizmor), and package classification via profiles (plugin, theme, forms, tables, library). For a TPM, the mental model is "org-wide engineering standard with an executable component," not "feature dependency." Fit is strongest where we ship multiple Filament packages under one template and want uniform quality gates; value is proportional to the number of packages in scope.

Integration feasibility. High. Adoption is a composer require --dev mortalkiller/filament-package-standard:^2.0 plus per-package profile selection and CI edits. Critically, the release states that Standard v2 adoption does not require a package major bump and that package SemVer remains driven by consumer-visible behavior — so this is a tooling change, not a consumer-breaking one. Existing packages are explicitly exempt from churn-only refactors (e.g., retrofitting spatie/laravel-package-tools), which materially lowers the cost of a first pass.

Technical risk. Low-to-moderate, concentrated in CI rather than production. Production runtime is untouched, so blast radius on end users is effectively zero unless a package's composer.json constraint is narrowed incorrectly. The real risks are delivery-side: Larastan level 6+ will surface a backlog of static-analysis findings on legacy code; stricter PHPUnit/Pest settings (warnings, risky tests, empty suites, randomized order) can flip previously-green builds red and expose order-dependent flakiness; Zizmor's Actions audit may fail existing workflows on permission/token patterns. Profile selection is a semantic decision that, if wrong, produces a too-narrow runtime dependency that later blocks panel integration.

Key questions.

• Is v2 conformance a hard release gate or advisory guidance for our packages?
• Which packages are in scope, and how does each map to a profile? Who arbitrates disputed classifications?
• What is the support/EOL policy for the Standard itself, and is its major version coupled to Filament majors?
• Do any of our packages still target PHP 8.1, given Standard v2 requires PHP 8.2+?
• What is the expected effort per package (baseline count, test-suite remediation, workflow edits), and is there a published migration checklist beyond the guide?
• Who internally owns the standard, and what is our pinning and upgrade cadence for ^2.0?

Integration Approach

Stack fit. Targets modern Laravel + Filament with PHP 8.2–8.5 verified. Because it is dev-only, it does not constrain our production dependency graph or consumer installs — the one hard compatibility boundary is the PHP 8.2 floor for the repositories themselves.

Migration path. Incremental and reversible. Adopt ^2.0 in require-dev on the current maintained major, classify each package to a profile, apply the narrowest runtime dependency (plugin/theme → filament/filament, forms → filament/forms, tables → filament/tables, library → filament/support), then layer the quality gates. Panel Plugin classes are only warranted where a package actually integrates with a panel — a useful cleanup signal for packages carrying vestigial plugin scaffolding.

Compatibility. Standard supports PHP 8.2+; packages on 8.1 need an explicit decision (upgrade, or stay on Standard v1). Migration from v1 does not force a package major, so v1 and v2 packages can coexist temporarily — this is what makes a staged rollout safe.

Sequencing.

1. Inventory packages, assign profiles, flag PHP 8.1 outliers and any package whose narrow dependency would be wrong long-term.
2. Pilot on one low-risk library-profile package end to end (dependency, .editorconfig, Larastan baseline, strict test flags, Zizmor, CI matrix).
3. Capture the delta as an internal migration runbook; size effort from the pilot's Larastan and test-failure counts.
4. Roll out in waves by profile, library/forms/tables first, plugin/theme after (larger surface, assets, Workbench, browser tests).
5. Add the Windows CI job for cross-platform-sensitive tooling packages last.
6. Distribute the developing-filament-packages skill via the Laravel Boost convention so scaffolding guidance lands in contributors' tooling, not just in docs.

Operational Impact

Maintenance. A new external dev dependency with its own major cadence. Cost is low per package but non-zero: pinned-range bumps, re-baselining Larastan as rules and Filament versions move, and keeping workflows aligned with Zizmor's baseline. Assign a named owner for the standard and a policy on how quickly we track ^2.x.

Support. Contributors will hit unfamiliar failures (Larastan, risky-test flags, Zizmor) before they hit unfamiliar concepts. The migration guide plus the Boost skill covers most of this; expect a short window of "why is CI red" tickets concentrated in the first wave.

Scaling. This is the package's main leverage: profiles plus opt-in capabilities make the N+1 package cheap and predictable, and narrower runtime dependencies reduce install surface and version-conflict risk across a growing portfolio. Uniform gates also make cross-package quality legible to non-authors.

Failure modes.

• CI red on legacy packages from stricter analysis — mitigated by baselining before enforcing.
• Flaky or order-dependent tests exposed by randomized execution; needs triage discipline, not disabling the flag.
• Zizmor blocking releases during a hotfix; needs a documented exception path.
• Profile misclassification producing an over-narrow Filament dependency that later blocks panel features.
• Partial adoption causing drift where some packages have .editorconfig/Zizmor/browser tests and others don't, making cross-package comparison misleading.
• Silent divergence if we fork template files locally instead of consuming the standard.

Ramp-up. Modest for authors already on Standard v1 (tooling delta only); larger for greenfield teams needing the Filament package-development model. Budget enablement around the skill, the migration guide, and the pilot runbook, and treat the first wave as a learning cohort rather than a deadline.