Tabler Icons Enum Laravel Package

Product Decisions This Supports

• Icon-set standardization. Choosing Tabler Icons (MIT-licensed, stroke-consistent) as the product's icon vocabulary is a design-led decision; this package makes that decision executable in Laravel code at near-zero cost, so the choice can be justified on visual/quality grounds rather than weighed against migration effort.
• Build vs. buy for "icon safety." The alternative is a 30–60 line generator that emits the same enum from the Tabler manifest. That build is roughly half a day to one day, so the "buy" case rests on convenience and upkeep, not on unique capability. This package is the adopt-now answer while that comparison is still open.
• Definition-of-done and review bar. Banning raw icon strings and requiring enum cases converts "does this icon render?" from manual QA into a static check. Unknown icon names fail silently in production (blank space, no exception), so a typed enum is the cheapest available control against that defect class.
• Design-token strategy. Typed icon names sit alongside color and spacing tokens as part of a design vocabulary. If the roadmap includes a design-system package or theming layer, a compile-time icon enum is a natural first increment and a template for typing the rest.
• Icon-vendor migration sequencing. If moving off Heroicons/Lucide/Font Awesome is a live option, the migration becomes a mechanical string→enum-case refactor with grep-able coverage. Deciding when to migrate is far easier when references are already enumerated.
• Configurability scope. Whether admins or tenants choose icons per resource, menu, or status. The enum supplies a validated allowlist for those rules without inventing a separate taxonomy of permitted icons.
• Dependency policy classification. With 1 star, 0 dependents, a single-line release note (2.0.1: Filament 5), and sparse docs, this lands in "low-risk, low-signal, adopt-or-generate." The Filament 5 note matters only if admin panels are Filament-based: it shows the package's major line tracks the lara-zeus/Filament cadence rather than Tabler's.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP 8.1+ and have already chosen (or are actively choosing) Tabler Icons — the package is useless for any other set.
• Icon references live in Blade templates, controllers, config, or Filament form/table option arrays, where a typo produces a silent visual defect rather than an exception.
• Multiple engineers touch UI code, so autocomplete and a shared vocabulary measurably reduce review friction.
• You want the smallest possible increment toward typed design tokens and can accept a micro-dependency instead of owning a generator.
• Your admin layer is on Filament 5 and you want the version of this package aligned with the current lara-zeus line.

Look elsewhere (or generate your own) when:

• You use a different icon set — the enum covers Tabler names only.
• You need runtime icon metadata (SVG paths, categories, search, weights) or database-driven icon selection. An enum gives names alone; you want an icon manifest table or a service backed by the icon package.
• Your organization restricts micro-dependencies. With one star, no dependents, and thin documentation, governance cost may exceed the cost of generating the enum in-house — and a generated enum is trivially replaceable.
• Your bundled front-end icon assets can drift from the enum. The enum's version must correspond to the Tabler release you actually ship.
• You are mid-migration between Filament majors. This is a major-version alignment, not a patch; sequence it after the Filament upgrade so regressions stay attributable.

Before committing, verify: the exact Tabler icon-set version the enum was generated from (and whether a generator script is published), whether the package truly requires Filament 5 or works framework-agnostically, and how enum case names map to what templates actually emit (ti ti-* classes vs. SVG sprite IDs).

How to Pitch It (Stakeholders)

To executives: This is a hygiene-level dependency, not a strategic bet. It gives us a type-safe, autocomplete-friendly list of icon names so UI code references icons through a checked identifier rather than free-text strings. The business effect is small but concrete: fewer silent UI defects (an unknown icon name simply renders blank), faster UI review, and a clean path if we ever change icon vendors. It is MIT-licensed, tiny, has no runtime logic, and is cheap to replace — the downside is bounded. Recommendation: adopt as a default for any Laravel surface using Tabler Icons; do not treat it as an architecture decision or allocate roadmap time to it.

To engineering: composer require lara-zeus/tabler-icons-enum, then replace icon string literals with enum cases in Blade, controllers, config, and Filament option arrays. You get IDE autocomplete, refactor-safe renames, and Enum::cases() for building validated icon-selection lists. Caveats to plan around: (1) the enum exposes names only — no SVG data, categories, or search; (2) release notes are a single line, so confirm version constraints and the Tabler release they map to before rollout; (3) keep the package major in step with your Filament major and the enum content in step with shipped icon assets. Add one governance test asserting every enum case resolves in our shipped icon set — that mitigation is what makes adoption safe. If dependency governance is strict, the fallback is generating the same enum from the Tabler manifest in an afternoon.

Ask: a short spike (under a day) to confirm version mapping, Filament compatibility, and correct class/SVG emission, plus a code-review rule that icon references must be enum cases. Named ownership sits with whichever team owns the design system or the admin UI that ships the icons.