schmeits/filament-4-phosphor-icons
Bring the Phosphor icon library to Filament 4 panels. Use thousands of crisp, consistent icons across forms, tables, actions, and navigation, with straightforward setup for Laravel admin interfaces.
Architecture fit. Unchanged in substance: a thin presentation-layer adapter, not platform infrastructure. The enum maps Phosphor icon names into Filament’s icon APIs, and the new render test through Filament’s icon component confirms it works through the framework’s own rendering path rather than a bespoke one. It still adds no service provider concerns, database, queue, or middleware beyond what the release notes now show as deliberate cleanup (the unused $viewNamespace property, phantom facade alias and factory namespace, and dead frontend tooling are gone). The value remains convenience and consistency: one enum vocabulary across six Phosphor weights. One architectural fact is now explicit rather than inferred: the enum is generated from codeat3/blade-phosphor-icons, so the real rendering dependency for SVG output is that upstream package, and this package owns only the mapping layer.
Integration feasibility. Still low effort, but with a firmer floor. composer require, then replace icon strings with enum cases. The release adds a hard gate: Filament 4.13.2+ or 5.8.2+ and codeat3/blade-phosphor-icons 2.4+. Those are the first versions without known security advisories, so feasibility now depends on the host application already being patched — an app lingering on Filament 4.11 or 4.12 must upgrade Filament before it can adopt this, which turns a trivial install into a two-step change with its own regression surface. Positively, the enum generator now lives at bin/generate-enum.php (composer generate-enum) and records the upstream version in the generated file, so regenerating against a newer Phosphor set is a supported, auditable operation rather than a maintainer-only ritual. Composer constraints should still be checked against the exact PHP, Laravel, Livewire, and Filament minor in use.
Technical risk. Reduced, but not eliminated. The confidence signals improved materially: CI across PHP 8.2–8.5, Laravel 12 and 13, and Filament 4 and 5; a render test through Filament’s icon component; a check that the committed enum matches the generator; PHPStan at max level on source, tests, and generator; strict types in every file. That is a serious testing and static-analysis posture for a package this size, and the enum-vs-generator check directly mitigates the “missing cases / drift” risk previously flagged. What has not changed: 17 stars, 0 dependents, single maintainer, no SLA. Adoption risk is now about continuity and the transitive dependency, not correctness. Because rendering flows through blade-phosphor-icons, its release cadence, SVG output, and any inline-SVG/CSP implications are part of our risk surface, not just this package’s. MIT licensing still limits legal risk; the new security-advisory floor is a governance benefit but also a coupling — the package’s constraint will drag Filament upgrades forward on its schedule as much as ours. PHP 8.2 remains the floor and Laravel 11 is now explicitly out of scope and untested.
Key questions.
blade-phosphor-icons 2.4+ is now a hard requirement, does it emit inline SVG or reference external assets, and how does that interact with our CSP and Vite config?icon-size-* classes, dark mode, and disabled states (the render test covers presence, not visual fidelity)?Stack fit. Good fit for Laravel 12/13 + Filament 4/5 + Livewire 3 + Tailwind admin panels. Laravel 11 is now out of scope and untested upstream, so it should be treated as unsupported in our own guidance. Filament 5 is now a supported target rather than a pre-release caveat, which removes the “wait for the ecosystem to catch up” argument and makes this viable for panels on either major. Phosphor’s weights map well to design-system states: regular for default, fill for active/selected, duotone for empty states or summaries. It remains a weaker fit for non-Filament frontends, and it still introduces a second icon language if the product standardizes on Heroicons.
Migration path. Start with one low-risk panel: confirm the application is on Filament 4.13.2+/5.8.2+ (upgrade first if not — that upgrade is its own reviewed change, not a side effect of installing an icon package), install, map the top 20 icons, replace hard-coded icon strings with enum cases, and compare rendering at every Filament size used. Then codemod remaining resources, actions, and widgets. Keep old icon strings until visual regression passes. For Filament 3 applications, upgrade Filament first or defer adoption; running two icon systems indefinitely creates governance debt.
Compatibility. Verify the package’s Filament constraint against the exact minor in use and confirm the codeat3/blade-phosphor-icons 2.4+ constraint resolves cleanly against our existing lockfile — this is the most likely source of a conflict, since it is a new hard dependency introduced upstream of us. Check PHP 8.2+ and Laravel 12/13 support, enum backing-value stability across releases, and whether the upstream package’s SVG output requires asset publishing or Vite configuration. Pin the package minor version, review changelogs before upgrades, and treat the recorded upstream version in the generated enum as the audit trail for which Phosphor set we are actually shipping.
Sequencing.
composer generate-enum), and upgrade cadence.Maintenance. Near-zero runtime maintenance; dependency maintenance is the real cost, and it is now a two-package surface. Pin both versions and review releases quarterly. Regenerating the enum when the upstream Phosphor set moves is now a documented, reviewable step — assign it an owner and run it as a routine PR rather than an ad hoc fix. With 0 dependents we remain an early adopter, but the CI matrix, generator-parity check, and PHPStan max level substantially lower the odds of silent breakage. Keep an internal fork mirror or vendored enum fallback if used in business-critical admin surfaces; the generator makes a fork more tractable than before.
Support. Community/single-maintainer support with no SLA, unchanged. New operational wrinkle: the package’s minimum Filament versions are driven by security advisories, so its release cadence can impose an upgrade deadline on us. Assign an internal owner for icon governance and define an escalation path: vendor the enum, fork under our namespace, or revert to local SVGs. MIT licensing makes a fork legally straightforward, but it still creates long-term ownership.
Scaling. The enum is compile-time and cheap at runtime. Scaling risk remains asset weight: six weights across a large icon set can bloat CSS/SVG payloads if everything loads, and with blade-phosphor-icons producing the SVG output, the purging story is that package’s behavior as much as ours. Load only the weights actually used and confirm Tailwind/Vite purging is effective. For multiple panels, centralize icon mapping in a shared design-system package to prevent drift.
Failure modes. Missing or stale enum cases are now caught earlier — the generator-parity test and CI matrix reduce, though do not eliminate, the chance of drift reaching production. Remaining failure modes: wrong weight selection producing inconsistent UI; a Filament upgrade exceeding the package’s constraint and blocking a security patch; a conflicting blade-phosphor-icons version in the lockfile; asset paths or CSP rules blocking inline SVGs; package abandonment leaving no upstream fixes. Mitigate with smoke tests that assert icons render at each size and state, a fallback icon, a documented fork plan, and a calendar reminder tied to Filament security advisories.
Ramp-up. Low for Filament developers — hours, not days. Designers need a weight/size mapping; QA needs visual regression coverage; one engineer should own the regeneration workflow. TPM leverage is tactical: accelerate admin UI polish and reduce custom SVG maintenance. The upgraded testing and static-analysis posture, plus first-class Filament 5 and Laravel 13 support, raise confidence enough to move from “adopt conditionally” to a one-panel pilot with a defined path to broader adoption — but the single-maintainer, 0-dependent profile and the newly inherited blade-phosphor-icons dependency mean broad standardization should still wait until the pilot passes and an owner is named.
How can I help you explore Laravel packages today?