- What is mortalkiller/filament-package-standard?
- It is a standardized development foundation and tooling contract for building Filament packages, not a runtime library. It bundles repository conventions, stubs, Workbench setup, CI quality gates, and package profiles. Install it in require-dev to scaffold and maintain consistent plugins with less boilerplate.
- How do I install mortalkiller/filament-package-standard?
- Require it as a development dependency with composer require --dev mortalkiller/filament-package-standard:^2.0. Then choose the appropriate profile for your package and update your CI configuration to match the standard. It is designed for the filament-package-template v2 architecture.
- Does filament-package-standard need to be installed in production?
- No. It sits entirely in require-dev and does not affect production runtime or consumer installs. Its value is in repository shape, CI, static analysis, and scaffolding during development. The main hard compatibility boundary is PHP 8.2 or higher for the package repository itself.
- Which Laravel and Filament versions does it support?
- It targets modern Laravel and Filament and is verified on PHP 8.2 through 8.5. It is built around the filament-package-template v2 architecture. Check the package constraints for exact Laravel and Filament version bounds before adopting it.
- What are the package profiles in filament-package-standard?
- Profiles classify packages as plugin, theme, forms, tables, or library. Each profile maps to the narrowest runtime dependency: plugin and theme to filament/filament, forms to filament/forms, tables to filament/tables, and library to filament/support. Choosing the correct profile matters because a too-narrow dependency can block panel integration later.
- Does adopting Standard v2 require a major version bump for my package?
- No. The release states that Standard v2 adoption does not require a package major bump, and package SemVer remains driven by consumer-visible behavior. This is a tooling change rather than a consumer-breaking one. It means v1 and v2 packages can coexist temporarily during a staged rollout.
- Should I replace spatie/laravel-package-tools with filament-package-standard?
- Not necessarily. Existing packages are explicitly exempt from churn-only refactors such as retrofitting spatie/laravel-package-tools. The standard governs conventions and quality gates, not a mandatory runtime package toolkit. Focus first on profile selection, CI, and static analysis where they add value.
- Why does my build fail after adding filament-package-standard?
- The stricter CI quality gates can expose issues that were previously hidden. Larastan level 6 or higher may surface a backlog of static-analysis findings, stricter PHPUnit and Pest settings can fail warnings, risky tests, empty suites, or order-dependent tests, and Zizmor may flag Actions permission or token patterns. Treat these as delivery-side remediation rather than production runtime risk.
- How do I migrate an existing package from Standard v1 to v2?
- Adopt ^2.0 in require-dev on the current maintained major, classify the package to a profile, and apply the narrowest runtime dependency. Then layer the quality gates and update CI. Migration does not force a package major, so v1 and v2 packages can coexist while you roll out gradually.
- What is the expected effort to adopt it across multiple packages?
- Effort scales with the number of packages in scope and their existing quality baseline. Expect work for profile classification, Larastan baseline remediation, test-suite fixes for strict flags, and workflow edits for Zizmor and the CI matrix. Piloting one low-risk library-profile package end to end is a practical way to capture the delta before broader rollout.