Filament 4 Phosphor Icons Laravel Package

Product Decisions This Supports

• Design language / brand differentiation. Phosphor ships six weights (thin, light, regular, bold, fill, duotone). That lets you encode hierarchy and state in the icon itself — a filled bell for "unread," a duotone one for "muted" — instead of relying on color alone. That is a product/design decision, not an engineering one, and this package is the cheapest way to execute it inside Filament.
• Build vs. buy for an icon layer. The artifact here is a maintained mapping table: every Phosphor glyph name → a backed enum case → Filament's icon size scale, across all six weights. That is tedious rather than hard. Building it in-house is roughly one to two dev-days plus perpetual curation; adopting it is a composer require. Buy.
• Filament 4/5 upgrade planning. Because the package targets Filament 4 and 5 only, the icon-set decision is really a sequencing decision: settle it as part of the upgrade, not after, or you will rework every ->icon() call twice. Note that 1.1.0 drops Laravel 11 (now end-of-life) and requires Laravel 12 or 13 — so the icon decision is now coupled to your Laravel upgrade window as well.
• Security-floor compliance. 1.1.0 requires Filament 4.13.2+ or 5.8.2+ specifically (the first Filament releases without known security advisories). If you run a patched-dependency policy, adopting this package nudges Filament itself up to the advisory-free floor rather than dragging you below it.
• Type safety as a quality bar. A backed enum gives IDE autocomplete and static-analysis coverage for icon references, so a typo'd icon name fails at analysis time instead of rendering as a blank space in a client-facing admin. The package now holds itself to that bar: PHPStan at level max across source, tests and generator, and strict_types in every PHP file. If you have a "no magic strings in the UI layer" rule, this is how icons comply with it.
• White-label / multi-brand admin panels. Weight and glyph are swappable per panel, which supports running one Filament codebase for several brands with different visual identities.
• Representative use cases: SaaS back offices, internal ops tooling, client-facing dashboards, and any Filament panel where the admin is a product surface rather than an afterthought.

When to Consider This Package

Adopt when all of the following hold:

• You are on Filament 4.13.2+ or 5.8.2+ (the security-advisory floor; there is no earlier-Filament path) and on Laravel 12 or 13 (Laravel 11 is EOL and no longer tested by this package).
• Your designers have standardized on Phosphor, or you specifically need weights Phosphor has and Heroicons does not (duotone and fill are the usual reasons).
• You value enum-typed icons over string literals, and you want them to inherit Filament's sm/md/lg sizing automatically so they do not break layout rhythm.
• You accept single-maintainer, low-adoption risk and are willing to vendor or fork the enum if it goes stale. The generator is now versioned and reproducible (composer generate-enum, upstream version recorded in the generated file, and a CI test asserting the enum matches the generator), which makes owning a copy a mechanical exercise rather than reverse-engineering one.

Look elsewhere when:

• You are on Filament 3 or earlier, or Laravel 11 and not yet upgraded.
• You are already on Heroicons with no design rationale to move — Filament ships a native Heroicon enum, and one fewer dependency is one fewer dependency.
• You need only a handful of icons; inline them.
• You have a strict dependency-minimization or security-review posture. 17 stars and 0 dependents is still thin adoption signal, and it remains a leaf dependency with one maintainer: bus factor 1. The 1.1.0 quality investments (PHPStan max, strict types, CI matrix on PHP 8.2–8.5 × Laravel 12/13 × Filament 4/5, render test through Filament's icon component) materially reduce the code risk but not the maintainer risk. Treat the enum as the deliverable and plan to own a copy.
• You need glyphs outside Phosphor's set, or proprietary icons — generate your own enum; it is the same amount of work.
• You need commercial support or an SLA.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed package that gives our Filament admin a distinctive, design-led icon language with state expressed by icon weight rather than color alone. Cost of adoption is a single dependency and hours, not weeks. The 1.1.0 release tightens the story: it pins us to Filament versions without known security advisories, tracks the current framework line (Laravel 12/13), and holds itself to max-level static analysis with CI across the supported matrix. Risk remains contained by design: the package is a type-safe enum of icon names whose source is now generated from a versioned upstream and verified in CI, so removing or replacing it is a find-and-replace, not a rewrite. Recommended: adopt, but pin and vendor the enum — the new generator makes that cheap — so a stale upstream cannot block us.

To engineering: It mirrors Filament's own Heroicon enum ergonomics — ->icon(Phosphor::House) — so it slots into existing conventions with no new abstractions, no service provider gymnastics (the unused $viewNamespace, facade alias and factory namespace have been removed), and no runtime cost beyond what Filament already does. It handles the full six-weight matrix and maps correctly onto Filament's icon size scale instead of hardcoding pixel sizes that drift. 1.1.0 is a quality release: strict types everywhere, PHPStan level max across source/tests/generator, CI render tests through Filament's own icon component, and a reproducibility check that the checked-in enum matches composer generate-enum. Low lock-in: the payload is strings, so migration cost is mechanical.

Diligence items to close before signing off: the Filament 5 version constraint is now resolved (4.13.2+/5.8.2+), as is the Laravel support window (12/13). Outstanding: confirm whether SVGs ship inline or via sprite (bundle-weight matters at ~1,200 glyphs × 6 weights), and confirm release cadence beyond this one — the maintainer count is still one and this is one release, so we should assume we may take ownership of the mapping; the versioned generator and enum-match test are the insurance policy for that outcome.