Tabler Icons Enum Laravel Package

Technical Evaluation

What this package is (and isn't). lara-zeus/tabler-icons-enum is a single-purpose data package: a PHP backed enum whose cases enumerate Tabler Icons names, plus a label() helper and a convenience accessor for Filament select/form options. There is no runtime logic, no persistence, no request-path code, and effectively no service-provider surface. This reframes the TPM decision: it is not a platform dependency, it is a vendored lookup table. It should be judged on the accuracy and stability of its case list, not on architecture. That framing keeps the decision appropriately small and keeps the downside bounded.

Architecture fit. Good fit where the organisation has already standardised (or is standardising) on Tablor—correction, on Tabler Icons—as the icon vocabulary for Laravel/Blade surfaces and Filament admin panels. The value proposition is narrow and real: icon references become type-checked identifiers rather than free-text strings, so a typo fails at analysis/review time instead of rendering blank space in production. Where the fit is poor: teams on Heroicons, Lucide, or Font Awesome get nothing; teams that need runtime icon metadata (SVG paths, categories, search, weight variants) get nothing; teams with a strict low-dependency-count policy should treat the build path as the default.

Integration feasibility. Mechanically trivial—composer require lara-zeus/tabler-icons-enum, PHP 8.1+ for backed enums, Composer autoload, reference cases in Blade/components/Filament option arrays. The genuine feasibility work is not installation but inventory and codemod: finding every hardcoded icon string across templates, config, and (hardest) database columns, and converting them file-by-file behind normal PRs. Budget that as an engineering task with a reviewer, not as a chore.

Technical risk.

• Version coupling (primary). The only release evidence is 2.0.1 — Filament 5. That tells us the enum's major line tracks the Filament release cadence, not the Tabler icon set. If we are on Filament 4, we likely need the 1.x line; if we are unconstrained by Filament, this coupling is dead weight we inherit for free.
• Upstream icon churn (medium). Tabler adds, renames, and deprecates icons between releases. Enum cases are identifiers: an upstream rename is a breaking change in our code, and a rename the package absorbs silently becomes a silent visual regression in admin UI—exactly the defect class the package is meant to prevent.
• Dual source of truth (medium). The enum lists names; the browser renders whatever Tabler CSS/sprite version we ship. Two independently versioned sources of icon names is a defect generator unless we pin and verify.
• Adoption signal (medium). 1 star, 0 dependents, single maintainer, terse single-line release notes, and a release date in the supplied metadata (2026-03-11) that reads as unreliable. None of this disqualifies a data package, but it removes "the ecosystem will catch regressions for us" as a mitigation and makes our own verification test non-optional.
• License (low, and the key mitigant). MIT. Fork-and-patch, or vendor the enum into app/Support/, is legally and practically available at trivial cost. State this explicitly in any approval—it is what makes the rest of the risk acceptable.
• Scale (low). A flat enum of thousands of cases is fine at runtime (opcache-resident) but costs IDE indexing and static-analysis time. Acceptable, worth knowing.

Key questions to put to engineering before approval.

1. Do we actually render Tabler Icons today, and in which surfaces (Blade, Filament, config, DB columns)?
2. Which Filament major are we targeting, and therefore which package major?
3. Which pinned Tabler version was the enum generated from, and does it match the asset we ship? Is the generator script published?
4. What do we actually emit—ti ti-* classes or SVG sprite IDs—and is the enum-to-markup mapping 1:1 and tested?
5. Are icons stored in the database? If so, what is the backfill and validation plan?
6. What is the 1.x → 2.0 breaking change, and is 1.x maintained for teams staying back?
7. What would generating this ourselves cost? (Realistic: half a day to one day for a script, plus a CI check.)

Integration Approach

Stack fit. PHP 8.1+ floor, Laravel 10/11/12, Blade, optionally Filament. Confirm from composer.json the PHP floor and the filament/filament constraint before committing—a raised PHP floor cascades into runtime images and CI with no product benefit. If we are not on Filament, adopt the enum content and treat the Filament helpers as unused convenience.

Buy-versus-generate, priced explicitly. Because the artifact is generated, the TPM should force the comparison rather than defaulting to "composer require":

Default recommendation: adopt for the spike; plan to generate or fork within a quarter if the package becomes load-bearing. The build cost is low enough that a single-maintainer dependency is a poor long-term trade for icon rendering in production admin UI.

Migration path.

1. Spike (half a day). Scratch Laravel app; install; render 3–5 representative icons in Blade and in a Filament select; confirm the emitted class/SVG resolves against our shipped Tabler asset version.
2. Inventory the blast radius. Grep for ti ti-, tabler-, and icon keys in config. Database-stored icons (e.g. a menu_items.icon column) are the hard part—those need validation rules and a backfill, not just a codemod.
3. Codemod, not big-bang. Replace literals with enum cases per file area. Keep a typed boundary helper (Icon::from(string)) wherever the value is user- or data-supplied.
4. Add the governance test. One test asserting every enum case resolves in our shipped icon set and every icon we reference exists as a case. This is the mitigation that makes the whole adoption safe, and it is the TPM's actual ask of engineering.
5. Document the bail-out. Pin the exact version in composer.lock, or vendor the enum into app/Support/ and drop the dependency. Both are one-day options; make the team name which one they'd take.

Compatibility. Package major must match Filament major; enum content must match the Tabler asset version actually shipped. Sequencing: do not bundle this with a Filament major upgrade. Upgrade Filament first, then adopt the enum, so any visual regression is attributable to one change. Roll out per feature area, with the governance test landing before the first production merge.

Operational Impact

Maintenance. Effectively zero at runtime; the real cost is refresh discipline. Each Tabler release adds icons the enum won't have (harmless) and may rename icons the enum still exposes (a breaking change for us). Standing cost: run the governance test on every icon or dependency change, and re-check the enum when we bump the Tabler asset. Assign a named owner—an unowned single-maintainer data dependency is the failure mode to avoid.

Support. No vendor SLA of any kind. Support path is the GitHub issue tracker of a one-maintainer project, with a documented MIT fork as the real fallback. Because the artifact is small and the licence permits it, "we take the generator in-house" is a credible, low-cost answer to abandonment—say so up front so it never becomes an escalation.

Scaling. Runtime scaling is a non-issue: an enum is compile-time data held in opcache, costing nothing per request. Scaling pressure is developer-experience only—a multi-thousand-case enum slows IDE indexing and static analysis. If that bites, filter at the point of use (Enum::cases() behind a helper returning a curated subset) rather than trimming the package.

Failure modes to plan for.

• Silent visual regression from an upstream rename or a mismatch between enum version and shipped asset. Mitigation: the governance test plus pinned versions.
• Drift on upgrade when Filament is bumped and this package lags. Mitigation: treat the package version as part of the Filament upgrade checklist.
• Abandonment. Mitigation: MIT fork or in-house generation, pre-costed at half a day to one day.
• Database-supplied icons bypassing the type system. Mitigation: validation rules built from Enum::cases() and a backfill.
• Governance friction in organisations that gate micro-dependencies. Mitigation: classify it as vendored data, not a platform dependency; the review should take minutes, not a design review.

Ramp-up. Under an hour for an engineer who knows PHP enums: install, browse cases via IDE autocomplete, swap literals. The learning is not the package, it is the org convention—"icon references must be enum cases"—which needs to be stated in the code review checklist and the definition of done for UI work. Without that convention the package delivers autocomplete and nothing else; with it, broken icons move from a manual QA step to a compile-time failure. That convention is the deliverable a TPM owns here.