Blade Entypo Laravel Package

Technical Evaluation

Architecture fit. owenvoke/blade-entypo is a presentation-only dependency: an auto-discovered service provider registers a Blade component namespace over a bundled directory of ~400 Entypo SVGs, with an optional publishable config for paths, prefixes, and default classes. No domain logic, no persistence, no events, no outbound calls, no runtime JS. For a TPM this is the cheapest dependency shape to justify — it is additive at the view layer, reversible without touching business logic, and its blast radius is exactly the set of .blade.php files that reference <x-entypo-*> or our alias. That containment is what makes it approvable at all in a codebase with any governance overhead.

Integration feasibility. composer require → optional vendor:publish → <x-entypo-home /> in a view. Realistic estimate: half a day to prove the pattern on one surface including design review, 1–2 days for a full rollout if template substitution is scripted. The genuinely non-trivial work is not engineering — it's two decisions plus an inventory: (a) build our own <x-icon> alias so the icon set is swappable, (b) fix the accessibility convention (decorative vs. meaningful) once, and (c) enumerate which glyphs are actually in use today across webfonts / Font Awesome / hand-copied SVG. Items (a) and (b) cost twenty minutes now and are expensive to retrofit after sixty templates bind directly to x-entypo-*.

Technical risk. Low on the engineering axis, materially higher on compliance and lifecycle — and the two are owned by different people, which is the real management point:

• Licensing — the gate, still unresolved. The package is MIT; the Entypo artwork is widely published under CC BY-SA 4.0 — attribution required, share-alike on the assets. MIT on the wrapper does not relicense the glyphs. v2.4.0 adds no NOTICE file and no license metadata change. Owner: legal/compliance, not engineering. Deliverable: a written read plus a decision on attribution placement (credits page or LICENSES file) before customer-facing exposure. Internal tooling can proceed in parallel.
• The glyph vocabulary is frozen. Entypo was effectively static by 2013–2014: no new glyphs, no optical-size variants, no accessibility remediation. A maintained wrapper does not fix an unmaintained icon set. Frame "dated visual language" as a product-design risk with a design owner, and pre-agree that missing icons become our own components alongside the alias — not a fork.
• Packaging is maintained, minimally. v2.4.0 is a community-contributed constraint bump to Laravel ^13, merged by a first-time contributor, containing zero features, fixes, or security content. Evidence of non-dormancy, not of investment. With 7 stars and 0 dependents, fork-and-vendor is a one-day contingency — the residual risk is a Packagist disappearance, not lost capability. Budget it as a contingency line, don't staff it.
• Compatibility churn is the live risk vector. The sole change in this release is a composer.json framework constraint, and the notes do not state whether it widened (added ^13 alongside earlier majors) or narrowed (replaced them). That is precisely the class of change that breaks a clean install or forces a transitive downgrade. Verify in a branch with a lockfile diff; do not assume semver protects you.
• Ecosystem drift — partially answered. The standalone ^13 bump confirms this is not a thin wrapper over blade-ui-kit/blade-icons (which would inherit that constraint). Consequence: swapping icon sets later is a template-touching migration unless the <x-icon> alias exists. That alias is the single highest-leverage deliverable in this workstream and should be an explicit acceptance criterion, not a nice-to-have.

Key questions to resolve before adoption.

1. Which license governs the bundled SVGs, and does the package ship attribution? (Unchanged and unanswered — still the gate for external surfaces.)
2. Does the 2.4.0 constraint add ^13 alongside existing majors or replace them, and what is the new PHP floor?
3. Inline SVG, <use> sprite, or external file — and what does that imply for CSP directives (img-src/style-src vs. inline markup) and DOM weight on icon-dense pages?
4. Are aria-hidden, focusable, and role guaranteed by the component, or entirely on us? (Evidence says entirely on us.)
5. Who signs off on the icon vocabulary — design, brand, or nobody? An unowned set becomes inconsistent by default.
6. What is the exit cost today, measured in files referencing x-entypo-* directly? That number is the argument for the alias.

Integration Approach

Stack fit. Ideal for Laravel + Blade + Tailwind. Inline SVG inherits currentColor, so sizing and colour are pure utility classes — size-5, text-gray-500, hover:text-black — and there is no @font-face, no FOIT, no asset-publish step, no sprite build. Works naturally in Blade-shell apps, Livewire components, and server-rendered Inertia pages because rendering is server-side and the output is markup. Does not fit Vue/React SFCs — those surfaces stay on their own SVG pipeline; do not attempt to duplicate the set there, and say so up front so no one plans for it.

Migration path. Three phases, each independently shippable:

1. Alias + convention (day 1). Ship resources/views/components/icon.blade.php wrapping x-dynamic-component with 'entypo-'.$name, enforcing aria-hidden="true" focusable="false" by default and role="img" + aria-label when a label prop is passed. Dynamic names must route through x-dynamic-component — you cannot interpolate into a tag, and menu config, status maps, and DB-driven icons all need this. Acceptance criterion: zero new direct x-entypo-* references after this lands.
2. Substitution (days 2–3). Replace <i class="entypo-*"> and ad-hoc SVGs with <x-icon>, verify visually, then delete the icon font files, @font-face declarations, and icon-font CSS. That deletion is the tangible win — fewer bytes on first paint. Map semantics to names once in config/icons.php (status → glyph, payment method → glyph, log level → glyph) so a new status is a config line, not a template hunt.
3. Enforcement (ongoing). Add a review checklist item and, if cheap, a lint/grep check in CI for direct x-entypo- usage outside the alias.

Compatibility. The version constraint is the gate, not the code. On Laravel 11/12, pin ^2.3 and accept that line as frozen. On Laravel 13, take ^2.4. Confirm provider registration before debugging anything else (php artisan about for the providers list; php artisan view:clear if a component "does not exist" right after install). Verify the constraint direction in a branch and read the lockfile diff — a framework-constraint release is exactly what forces a transitive downgrade.

Sequencing.

• Week 0 (parallel): legal opens the Entypo license read; engineering proves the alias on one low-risk internal view; design confirms the vocabulary is acceptable for the surfaces in scope.
• Week 1: alias merged, convention documented, glyph inventory complete (which of the ~400 are actually used).
• Week 2: substitution on internal/low-traffic surfaces only; measure DOM weight and payload on one icon-dense table.
• Gate: legal sign-off → external/customer-facing surfaces. Internal surfaces do not wait on legal; external ones do. Sequencing the gate this way is the single decision that keeps the workstream off the critical path.
• Week 3+: delete webfont assets, close out, add CI check.

Operational Impact

Maintenance. Near-zero steady state: no config to keep in sync, no assets to rebuild, no version cadence to track beyond the Laravel constraint. The real maintenance surface is our alias component and the config/icons.php mapping — both small and both ours. Upstream cadence is roughly one constraint bump per Laravel major, so budget a few hours per major-version cycle, plus a lockfile verification step. Do not build a process around this package; build it around the alias.

Support. No vendor, no SLA, no support contract — a single maintainer and a first-time contributor on the most recent release. That is acceptable because the surface is tiny (a provider plus a directory of SVGs). The support plan is the contingency, not a contract: if upstream goes quiet, fork-and-vendor is a one-day job, and the <x-icon> alias means no template changes. Document that contingency in the repo README so it survives staff turnover. Support burden on the team is genuinely low; the predictable tickets are "icon name typo" and "colour not applying."

Scaling. Scales fine on request volume — there is no runtime cost beyond rendering inline markup. The scaling concern is DOM weight and payload, not throughput: a 200-row table with three icons per row is 600 inline <svg> elements on the wire. Acceptable, but measure before assuming. Policy: icons on summary/detail views; if a dense listing shows up in profiling, drop to a single icon per row or render text-only. Also watch class-merge ordering — if a default size class wins over a passed one, inspect the final class attribute rather than reaching for !important.

Failure modes. Ranked by likelihood × impact:

Ramp-up. Very shallow for any Laravel dev — the API is a Blade tag and the README is sufficient. Realistic ramp: under an hour to first productive use, half a day to be fluent including the dynamic-component and alias patterns. The friction is entirely in the two upfront decisions (alias, accessibility convention) and the glyph-name inventory, not in the tool. Budget onboarding as: read the alias component, bookmark the SVG directory listing, done. New hires should never learn <x-entypo-*> directly — they should learn <x-icon>, which also means the underlying package can be replaced without retraining anyone.