Blade Entypo Laravel Package

Product Decisions This Supports

• Build vs. buy vs. depend for iconography. The core decision this package unlocks is "how do we get icons into the product" — custom SVG pipeline, design-system investment, or a Composer dependency. Blade Entypo collapses what is normally a design-system workstream (glyph sourcing, sprite generation, asset publishing, font hosting) into one composer require and a one-line <x-entypo-name /> call. A PM can commit to consistent icon treatment on a surface without a designer, an SVG hand-off process, or a build-pipeline ticket.
• Scoping a feature surface without an icon line item. Empty states, nav items, status badges, table row actions, form validation affordances, and dashboard KPI cards all need glyphs. With this package there is no "icons" line in the estimate — it becomes a template detail. That is a real schedule decision, not a technical one.
• Roadmap sequencing for design-system work. If the roadmap has a "unify iconography" initiative, this package is a credible interim or terminal answer. The PM decision is whether to fund a bespoke icon programme or accept a frozen, generic vocabulary now and revisit when brand differentiation matters.
• Exit optionality as an architectural decision. Because the package registers as its own Blade component namespace (v2.4.0 bumps Laravel to ^13 as a standalone registration, not a thin wrapper over blade-ui-kit/blade-icons), swapping icon sets later is a template-touching migration — unless the team introduces a <x-icon> alias component on day one. The PM-relevant call: mandate the wrapper at adoption so "switch icon sets" stays a one-file change and never becomes a roadmap item.
• Accessibility convention as a product requirement. The package ships no labels, role, or title guarantees. Every icon is either decorative (aria-hidden="true") or meaningful (role="img" + aria-label). This is a compliance decision, and it should be enforced centrally in the alias component rather than left to review discipline across dozens of templates.
• Licensing and attribution placement. MIT covers the package; the Entypo glyph artwork is commonly published under CC BY-SA 4.0, which carries attribution and share-alike obligations. That is a product decision — where the credit lives (credits page, footer, LICENSES file) — with a legal read required before customer-facing exposure.
• Performance trade-offs on icon-dense surfaces. Each icon is an inline <svg> in the DOM. A 200-row table with three icons per row is 600 SVGs on the wire. Acceptable for most apps, but it is a decision to measure rather than assume: if payload or DOM weight shows up in profiling, restrict icons to summary/detail views.
• Vocabulary freshness as brand risk. Entypo has not meaningfully grown since the early 2010s. Accepting it means accepting a dated visual language and a set that will not gain glyphs. That belongs in the design-review conversation, not the engineering backlog.

When to Consider This Package

Adopt when:

• You are on a server-rendered Laravel Blade app (including Livewire and server-rendered Inertia pages) with Tailwind. The SVG output inherits currentColor, so sizing and colour are just utility classes — no font files, @font-face, or asset-pipeline step.
• The glyph vocabulary you need is generic UI iconography — arrows, status marks, common actions, file types. Roughly 400 glyphs cover most administrative and dashboard surfaces.
• You are replacing an icon webfont (<i class="entypo-*">). This is the clearest win: fewer bytes on first paint, no FOIT, and deletable font artefacts.
• You want the icon decision to be cheap and reversible — a provider plus an SVG directory, vendorable or forkable in about a day if Packagist goes quiet.
• You are willing to invest a day up front in an alias component and an accessibility convention before templates start referencing x-entypo-* directly.

Look elsewhere when:

• You need brand marks, product logos, or a distinctive visual identity. A frozen generic set will read as dated.
• You need multiple weights, duotone, or optical-size variants — or an icon vocabulary that is actively growing. Heroicons or Lucide are the obvious comparisons; both are maintained and Blade-integrated.
• Your UI lives substantially in Vue/React SFCs. These components render server-side only; those surfaces need their own SVG pipeline, and running two icon paths creates inconsistent optical sizing and two future migrations.
• You need accessibility baked in rather than a convention you enforce yourself.
• You need licensing clarity without a legal review, or a support/SLA relationship with a vendor. This is one maintainer, seven stars, zero dependents, and its most recent release is a community-contributed framework-constraint bump with no features or fixes.
• You have a hard performance budget on icon-dense views and cannot accept inline SVG duplication at scale.

Verify before committing: does the 2.4.0 constraint add Laravel ^13 alongside earlier majors or replace them, and what is the new PHP floor? The release notes do not say, and a framework-constraint release is exactly the change class that forces a transitive downgrade. On Laravel 11/12, pin to ^2.3 and treat that line as frozen.

How to Pitch It (Stakeholders)

To executives: "Icons are needed on every surface we ship — navigation, status, empty states, tables. The build alternative is a design-system workstream with ongoing cost; this is a single dependency that turns each icon into one line of template code. Integration is roughly half a day to prove on one view and one to two days to roll out. It is purely additive at the presentation layer — no business logic, no data, no external service — so it can be removed without touching the product. The two things to resolve are not engineering problems: the glyph licence needs attribution placement, and the icon set itself is dated and will not grow. Both are decisions we should make deliberately now rather than discover at launch."

To engineering: "Auto-discovered service provider, bundled SVGs, anonymous Blade components. No config edits, no published assets, no runtime dependencies. Output is inline SVG inheriting currentColor, so Tailwind handles colour and size. Two asks: build the <x-icon> alias component on day one so a future swap to Heroicons or Lucide is a one-file change rather than a template-wide hunt, and put the decorative-vs-meaningful accessibility decision inside that component so it cannot be forgotten. Dynamic and config-driven icon names go through x-dynamic-component; semantic mappings belong in config or enums, not Blade @switch blocks. Add php artisan view:cache to the deploy script — anonymous components resolve at view-compile time, so a stale compiled view is the usual "the new icon didn't appear" suspect."

The one-line summary: low-cost, low-coupling, easily reversed — the risks are licensing and a frozen vocabulary, and both are ours to manage, not the package's to solve.