Filament Package Template Laravel Package

Product Decisions This Supports

• Build vs. buy for internal plugin scaffolding. This package is a project template, not a runtime dependency: it answers "do we hand-roll a starter kit for our Filament plugins, or adopt a maintained one?" Adopting it removes the recurring cost of maintaining our own scaffolding, CI matrix, and static-analysis baseline.
• Standardizing Filament extension development across teams. The five profiles (plugin, theme, forms, tables, library) map directly onto the extension types we actually ship, so a single template can serve multiple product lines instead of each team inventing its own skeleton.
• Platform upgrade roadmap (Laravel 12 → 13, PHP 8.2 → 8.5, Filament 5.x). The release is verified at the lowest supported boundary (PHP 8.2 + Laravel 12 + Filament 5.8.1) and at the leading edge (PHP 8.5 + Laravel 13), which gives us a defensible answer when planning when to drop older runtime support.
• Quality-gate investment. Larastan level 6+, strict PHPUnit configuration, Zizmor GitHub Actions auditing, and 100/100 PlumbPHP Ecosystem, Maintenance, Security, and Composite scores mean adopting this template is also a decision to inherit a security and maintainability posture rather than negotiate one per project.
• Remediation decision for early adopters. Anyone who installed v2.0.0 is on source that was mistakenly tagged from the pre-v2 template. Upgrading to ^2.0.1 is a correctness fix, not a nice-to-have — treat it as a required follow-up action with a named owner.
• Developer-environment inclusivity. Windows compatibility testing for the template tooling is a real adoption unblocker if any part of the team develops on Windows; without it, template tooling becomes a "Mac/Linux only" tribal-knowledge problem.

When to Consider This Package

Consider it when:

• You are building two or more Filament plugins, themes, or form/table extensions — the payoff from a shared scaffold scales with count.
• You want a pre-negotiated quality baseline (Larastan 6+, strict PHPUnit, CI auditing, Rector) instead of relitigating tooling on every new repository.
• Your support matrix spans PHP 8.2–8.5 and Laravel 12–13, and you need scaffolding that is verified at both the floor and the ceiling rather than only on the maintainer's machine.
• You have Windows-based contributors and need tooling that is tested there.
• You are comfortable with opt-in scaffolding — config, migrations, views, translations, stubs, assets, Workbench, browser tests, and Rector are all selectable, so you are not forced into a maximal skeleton.
• You are already inside or willing to accept the mortalkiller/filament-package-standard:^2.0 ecosystem and its conventions.

Look elsewhere when:

• You are not using Filament — nearly all the value here is Filament-specific.
• You are shipping a single, one-off plugin. The template's opinionated CI matrix and standards add surface area that a lone package cannot amortize.
• You need a runtime library rather than a project generator. Laravel Package Tools covers runtime scaffolding, but the artefact you adopt here is a starting shape, not an ongoing dependency.
• You require profiles or conventions outside the five offered, or need to diverge substantially — at that point you are maintaining a fork and lose the upgrade path.
• You have a hard policy against template/vendor coupling or require first-party (Laravel/Filament org) scaffolding only.
• You need a stable, long-tenured release history. This is the first correctly published stable release of v2, following a mis-tagged v2.0.0. That is a healthy recovery, but it is a short track record; teams with low tolerance for early-lifecycle churn should pilot rather than standardize.

How to Pitch It (Stakeholders)

For executives: We are standardizing how we build Filament extensions. This template gives every new plugin the same security auditing, static analysis, test configuration, and multi-version support matrix on day one, instead of each team rebuilding that from scratch. It is verified across PHP 8.2 through 8.5, Laravel 12 and 13, and on Windows, which de-risks our platform upgrade planning and means we can state precisely which runtime versions we support. The release carries top scores on the maintainer's ecosystem, maintenance, security, and composite health checks — the kind of signal we would otherwise have to produce internally. Cost is low and the payoff is consistency; the main caveat is that v2 is young, so I recommend piloting on one active plugin before making it the default.

For engineering leads: The template is a scaffold, not a runtime dependency — you generate a correctly shaped package and then own it. Everything is opt-in: config, migrations, views, translations, stubs, assets, Workbench, browser tests, and Rector are chosen per project, so lean plugins stay lean. You get Larastan level 6+, strict PHPUnit, Zizmor Actions auditing, and Laravel Package Tools-based runtime scaffolding without writing the boilerplate. Compatibility is explicitly tested at the lowest supported boundary (PHP 8.2 + Laravel 12 + Filament 5.8.1) and at PHP 8.3/8.4/8.5 on Laravel 12/13, plus Windows. One action item: if any repository was generated from v2.0.0, update to ^2.0.1 immediately — that tag was cut from the pre-v2 source and is not the intended implementation. No tags were moved or reused, so the upgrade is a clean composer require.