Filament Phosphor Icons Laravel Package

Product Decisions This Supports

• Deciding the icon language once, and enforcing it in code review. Admin surfaces today inherit Filament's Heroicons default plus whatever gets pasted in ad hoc — navigation groups, resource actions, row actions, IconColumn status indicators, badges, toggles, empty states, notifications. One composer require converts "Phosphor everywhere" from a style-guide wish into a reviewable rule. Log it as a consistency play, not an architecture commitment.
• Collapsing the design→dev handoff for iconography into a named reference. Because every icon resolves through an enum case (Phosphor::StarBold), a spec can say "use Phosphor::Palette for the theme picker" and engineering implements exactly that — no SVG exports, no asset pipeline, no "which of these three star icons is correct" round trip. This is the highest-leverage, lowest-cost thing the package buys, and it's a process win more than a technical one.
• Encoding visual emphasis as a product convention rather than per-component styling. The Weight enum with forceWeight() and fluent shorthands (->bold(), ->fill(), ->duotone(), ->thin()) let you write down rules — primary action = bold, secondary = regular, active/selected = fill, decorative = duotone — that survive review instead of dissolving into case-by-case overrides. Budget about an hour of design agreement; that is the real cost of this capability.
• Build vs. buy: a shallow, obvious buy. MIT-licensed, pure PHP, no service, no published assets, no frontend build, no database. It is a generated mapping catalogue over an icon set you would otherwise hand-roll. The genuine alternative is buying nothing and keeping Heroicons — which is legitimate, and that tradeoff should be stated plainly rather than buried in a footnote.
• Removing one objection from a Filament roadmap conversation. If you are evaluating or expanding Filament as the admin framework, a credible icon story deletes one "we'd have to build that ourselves" item. Be candid about magnitude: this is a footnote in a framework decision, never a driver of one.
• Use cases worth scoping against explicitly: CRUD action icons in resource tables; toggle on/off state pairs (StarFill / Star); boolean and enum status columns; notification and empty-state visuals; onboarding and empty-first-run flows; multi-tenant dashboards where tenant-branded shells must still share identical iconography underneath.
• Treating icon coverage as an operating cost, not a project. php artisan phosphor:sync (--dry-run, --enum-path) regenerates the enum from upstream, so new Phosphor icons are not gated on the maintainer cutting a release. This materially changes the maintenance calculus and is why adopting a 5-star, single-maintainer package is defensible here in a way it usually isn't: the catalogue is generated data you can refresh on your own schedule, not logic you depend on.
• An accessibility guardrail decided alongside adoption. Icons are decorative by default and the package does nothing to force labels. If you adopt, pair it with a rule that icon-only actions always carry a tooltip or aria-label, and that an icon is never the sole carrier of meaning in a status column. Cheap to decide now, expensive to retrofit across a shipped admin.
• A pilot-and-rollout estimate you can plan against. Roughly one day to stand up a pilot page (install, swap imports, validate rendering in light/dark across a couple of resource screens), then two to three more days for rollout. The remainder is mechanical.

When to Consider This Package

Adopt if:

• You are on Filament 4 or 5 and have already chosen — or are actively leaning toward — Phosphor as your icon language. This package does not help you choose an icon set; it executes a decision you've already made. Absent that prior decision, it delivers nothing.
• You want type-safe icon references, so a mistyped, renamed, or removed icon fails in development rather than rendering as a blank box in a customer-facing admin screen.
• You want weight and emphasis control as a reviewable product convention instead of CSS overrides fighting Filament's icon classes.
• You are prepared to treat a single-maintainer, 5-star, 0-dependent package as vendored code: version-pinned, reviewed on upgrade, forkable. The sync command keeps a fork viable because the enum is generated data, not hand-maintained logic.
• You would otherwise hand-roll your own icon enum. If someone is writing app/Enums/Icon.php anyway, this is a free upgrade.

Look elsewhere if:

• You are not on Filament. This is a Filament-shaped artifact with no utility outside it, and 0 dependents means no community evidence of it working anywhere else.
• You have no opinion on Phosphor. Filament ships Heroicons at zero cost and zero added dependency. Adopting this means adding a dependency specifically to get a different icon set. Say so in the decision record: the decision is the icon set; the package is an implementation detail.
• You need vendor assurance. No SLA, no security programme, no stated release cadence, no advisory process. If policy requires a supported dependency for customer-facing surfaces, this fails the bar — inline the enum instead.
• Admin bundle weight is a tracked metric. Phosphor is large and the enum exposes the full catalogue, not a curated subset. Curating or tree-shaking pushes you back into maintaining your own list, at which point the package's value drops sharply.
• You are on Filament 3, or a major the package hasn't been updated for. Version coupling is the primary ongoing risk; the 1.3.0 release adding Filament 5 support is the pattern to expect, and the lag between a Filament major and a matching release is your exposure window.
• You need dynamic or generated iconography — per-tenant logos, runtime SVG manipulation, non-SVG formats. This is a static enum.
• Your design system is already committed elsewhere. Swapping icon languages mid-product is a design and QA cost that dwarfs any velocity gain here.

How to Pitch It (Stakeholders)

For executives (30 seconds): "A small, free, MIT-licensed library that gets our admin screens onto one consistent, modern icon set instead of a patchwork of framework defaults and one-offs. The upside is modest but real: less design churn, fewer visual inconsistencies in tools customers actually look at, no licence cost, no new infrastructure, no security surface. The honest caveat is that it's a tiny community package with a single maintainer, so I'd treat it as a low-stakes tactical choice with a trivial exit — worst case we copy a few hundred generated lines of icon names into our own repo. This is not a strategic bet and I wouldn't spend committee time on it."

For engineering: "It's a thin, pure-PHP enum mapping Phosphor icon names into Filament's existing icon() API. No meaningful service-provider behaviour, no middleware, no published assets, no JS, no database. What you get: compile-time-safe icon references (Phosphor::StarBold), a Weight enum with forceWeight() and per-weight shorthands, Blade usage via @svg / svg() / <x-icon>, and php artisan phosphor:sync (--dry-run, --enum-path) to regenerate the catalogue when Phosphor ships new icons — so we're never blocked on upstream releases. Integration is a composer require plus import swaps. Risks: single maintainer, thin test surface, 0 dependents, and coupling to Filament's icon contract across majors. Mitigation: pin the version, add one smoke test over our icon call sites, and accept that if it's abandoned we vendor the enum — it's generated data, not logic. Budget a day for a pilot page and two or three more for rollout; the work is almost entirely mechanical."