Ux Fontawesome Laravel Package

Product Decisions This Supports

• Icon delivery strategy for the UI layer. Choosing between three concrete options: vendored icon assets compiled into the app, CDN-linked icon fonts, or icons resolved at render time through a Twig/Blade component. This package takes the "vendored + component" position — useful as a reference model even if you don't adopt it.
• Build vs. buy vs. wrap. It is a thin wrapper, not a product. The decision it informs is whether your team maintains a private icon wrapper or adopts the standard upstream path (symfony/ux-icons + Iconify on Symfony; a Blade component + @fortawesome/fontawesome-free npm on Laravel). Rarely worth building your own; this package is one organisation's build of that wrapper.
• Supply-chain and GDPR posture. Self-hosting icon fonts removes third-party CDN calls at render time — a real checkbox for privacy review, offline/air-gapped deployments, and CSP hardening. This is the strongest product argument the package supports.
• Stack standardisation. The package is explicitly scoped to Krystal Symfony projects. It supports a "do we standardise an icon component across our apps?" conversation — but for Symfony estates only. For Laravel, its value is as a design reference, not a dependency.
• Maintenance budgeting. Zero stars, zero dependents, single-org provenance means you own it the moment it enters composer.json. The decision it supports is whether icon rendering is core enough to carry that overhead versus a two-line npm import.
• What it does not support: roadmap prioritisation, pricing, customer-facing differentiation, or any measurable product metric. Icons are table stakes — this is infrastructure hygiene, not a feature bet. Do not spend PM cycles defending it in a planning review.

When to Consider This Package

Consider it when:

• You are inside the Krystal Symfony estate and already run Symfony UX (Twig components, AssetMapper or Webpack Encore). The package assumes that stack and will not drop into anything else.
• You specifically need Font Awesome Free, vendored rather than CDN-linked, with a Twig-level API in front of it.
• You want the icon layer version-pinned and auditable by your own team, and you accept owning Font Awesome major-version upgrades.
• Your alternative is a homegrown Twig extension — a shared internal package is marginally better than five divergent copies.

Look elsewhere when:

• You are on Laravel. There is no service provider, no Blade component, no Vite integration. The correct answer is a Blade component plus the @fortawesome/fontawesome-free npm package, or blade-ui-kit/blade-icons.
• You need Font Awesome Pro — this is Free-only by name and by licence.
• You need only a handful of icons and care about payload size; tree-shaken SVGs or symfony/ux-icons with on-demand fetching beat shipping the full Free set.
• You need a community-vetted dependency. Zero stars, zero dependents, no issue history — treat it as unvetted internal code until proven otherwise.
• You need multi-framework parity (React/Vue/design-system consistency) or accessibility tooling beyond what FA Free offers.
• You need icon sets beyond Font Awesome — Iconify's catalogue is the broader play.

Pre-adoption checklist: confirm the licence chain (FA Free icons CC BY 4.0, fonts SIL OFL 1.1, code MIT — attribution obligations flow through to your product); verify the pinned FA version; determine AssetMapper vs. Encore support; confirm the icon prefix (fa? fas/far/fab? a getPrefix() method?); and name a single owner for upgrades and the eventual replacement.

How to Pitch It (Stakeholders)

To executives: This is a small internal utility that packages Font Awesome Free icons for Symfony applications so teams stop wiring up icon fonts five different ways. No licensing cost, no vendor lock-in, and a modest privacy win because assets are self-hosted rather than pulled from a third-party CDN at page load. It is not a strategic investment and will not move a customer metric — approve it as housekeeping, or skip it and let teams use standard upstream tooling. Either way the cost is measured in engineering hours, not budget. The only real risk is quiet ownership: a zero-star, single-org package has no external safety net, so someone must be named as maintainer before it ships.

To engineering: Adopt only if you're in a Symfony UX codebase and want FA Free vendored behind a Twig API. Be clear-eyed: zero stars, zero dependents, single-organisation provenance — you are the maintainers now. Audit the pinned Font Awesome version and licence headers before it lands in composer.json, confirm AssetMapper vs. Encore support, and verify it degrades sanely when an icon name is wrong rather than throwing on every page. Wrap it behind one internal icon() macro so swapping to Iconify, Heroicons, or plain SVGs is a single-file edit. If you're on Laravel, stop — use a Blade component with the npm package; this integration layer does not port, and you'd be writing the adapter yourself. If your real need is a broad, maintained icon set, evaluate symfony/ux-icons with Iconify first and treat this package as the fallback only if Font Awesome specifically is a hard requirement.