Filament Package Standard Laravel Package

Product Decisions This Supports

• Build vs. buy for plugin distribution: This release sharpens the decision to standardize on Filament-first packaging rather than hand-rolling a plugin architecture. The plugin / theme / forms / tables / library profiles give a defensible mapping from product scope to dependency footprint, so a PM can scope an extension or add-on product with a known surface area instead of an open-ended one.
• Roadmap sequencing for extensibility: Because profiles use the narrowest runtime dependency (e.g. filament/tables rather than the full filament/filament), we can ship a focused capability as a standalone package and defer a full panel integration. That lets us sequence "tables-only add-on" ahead of "full admin panel product" without rework.
• Quality investment and maintenance cost modelling: Formalizing opt-in capabilities (config, migrations, views, translations, stubs, assets, Workbench, browser tests, Rector) turns "how much maintenance does this package cost us?" into an explicit checklist rather than an estimate. Larastan level 6+, stricter PHPUnit/Pest configuration (warnings, risky tests, empty suites, randomized execution), and Zizmor as a workflows security baseline raise the floor and make ongoing upkeep a predictable line item.
• Compatibility commitments to customers: Evidence-based minimum/latest version requirements plus verified runs on PHP 8.2–8.5 let us publish a support matrix we can actually honor, and Windows CI guidance de-risks selling to teams on mixed-OS environments.
• Release-management policy: The explicit statement that adopting v2 tooling does not force a package major — SemVer stays driven by consumer-visible API/behavior/compatibility — is a directly usable policy. It permits adopting better CI and static analysis on already-shipped majors, so quality work does not have to be bundled into a customer-facing breaking release.
• Use cases it unlocks: distributing Filament plugins/themes through the ecosystem with credible quality signals; packaging internal admin functionality for reuse across client projects; standing up a forms- or tables-level extension without committing to a panel product.

When to Consider This Package

Adopt when:

• You maintain one or more Filament plugins, themes, or extractable packages, or plan to publish to the Filament ecosystem and want conventional structure, CI, and analysis defaults that reviewers and customers recognize.
• You want consistent, auditable quality gates across a portfolio of packages rather than per-repo improvisation — this is the core value, and it compounds with package count.
• You are starting a new package: the profile guidance and spatie/laravel-package-tools preference mean greenfield packages get the intended shape with no migration cost.
• You need a defensible compatibility matrix for customers (PHP 8.2–8.5, evidence-based min/latest constraints) and cross-platform CI confidence.
• You already use Laravel Boost conventions and want the developing-filament-packages skill as the onboarding path for contributors.

Look elsewhere or defer when:

• You ship a single application with no reusable package boundary — the profiles, Workbench, stub and asset opt-ins, and migration guidance mostly encode problems you do not have.
• Your team has no capacity to own the raised bar. Larastan level 6+, Zizmor, and strict Pest settings (risky/empty-suite failures, randomized execution) generate real remediation work on legacy packages; adopting the standard without funding the cleanup produces a red CI that everyone learns to ignore.
• You are not on PHP 8.2+. The Standard package itself requires 8.2, so this is a hard prerequisite, not a preference.
• Your stack is not Filament-based. The dependency profiles and panel-Plugin expectations are Filament-specific; only the generic CI/analysis ideas transfer, and those are available directly from Larastan, Pest, and Zizmor.
• You need strictly zero tooling churn in the near term. Note that existing packages are explicitly not required to do churn-only runtime refactors, so partial adoption is viable — but full adoption is a scheduled initiative, not a drive-by change.

Adoption stance on v2.0.0: this is a major version of the standard, not a breaking change to our products. It is opt-in, migration guidance is provided, and no package major is implied. The correct move is to adopt for new packages immediately, and queue existing packages onto v2 tooling within their current maintained majors, funding static-analysis remediation as explicit work rather than treating it as free.

How to Pitch It (Stakeholders)

For executives: This is a major update to the development standard our Filament packages are built against — process and tooling, not customer-facing product behavior. It reduces the cost and risk of shipping and maintaining our package portfolio by standardizing structure, dependency footprint, automated quality checks, and security auditing. Critically, it does not force a breaking release: we can adopt the improved tooling on currently supported versions, so customers see no disruption while our defect and maintenance exposure goes down. The main ask is modest engineering time to bring existing packages up to the new analysis and CI baseline; new packages get it for free. It also gives us a support matrix (PHP 8.2–8.5) we can put in front of customers with confidence.

For engineering: v2 aligns the workflow with the filament-package-template v2 architecture. Choose the narrowest Filament dependency that matches actual behavior (plugin/theme → filament/filament, forms → filament/forms, tables → filament/tables, library → filament/support); panel Plugin classes only where a package genuinely integrates with a panel. New runtime packages should prefer spatie/laravel-package-tools — existing packages need no churn-only refactors. Defaults now include Larastan level 6+, stricter Pest/PHPUnit settings, Zizmor for GitHub Actions security auditing, .editorconfig, and evidence-based min/latest constraints, with Windows CI guidance for cross-platform-sensitive tooling. Install with composer require --dev mortalkiller/filament-package-standard:^2.0. Expect real work on legacy repos to reach the analysis baseline and green strict test settings; sequence that remediation deliberately, and treat the v1→v2 migration guide and the updated developing-filament-packages skill as the onboarding path.