Ux Icons Js Bundle Laravel Package

Product Decisions This Supports

• Runtime-determined iconography (the core unlock). Icons whose names come from data rather than source — tenant branding, admin-configurable navigation, CMS/rich-text content, plugin manifests, user-saved dashboard layouts — can now be rendered without a build step. Previously this forced either a full icon-set bundle or an in-house loader; that trade-off is now a product decision rather than an engineering constraint.
• Build vs. buy on the icon pipeline. The package now owns manifest generation (var/icons/), per-icon module splitting (loaders.js), the fetch/cache primitive (loadIcon(loaders, name)), and framework bindings (UXLazyIcon). This is a "buy" argument: the remaining in-house work is naming conventions and fallback design, not infrastructure.
• Bundle-size vs. flexibility roadmap items. Shipping every icon is no longer the only way to support dynamic names. Teams can defer "we can't offer icon customization until we shrink the bundle" and schedule it directly.
• White-label / multi-tenant and personalization bets. Tenant-specific icon sets become viable without per-tenant builds, since only the requested icon is fetched.
• Frontend framework commitment. The React and Vue components are first-class citizens here; this reinforces a React/Vue frontend assumption in the roadmap and is a data point against adopting a different view layer for icon-heavy surfaces.
• Scope boundaries to decide explicitly. Whether lazily loaded icons are acceptable for above-the-fold chrome (they are not, generally) versus secondary or content-embedded surfaces (they are). This is a product judgment about perceived performance, not a technical one.

When to Consider This Package

Adopt when:

• Icon names are genuinely unknown at build time — sourced from an API response, database row, tenant config, or user input — and the set is open-ended or large.
• The stack is already Laravel with a React or Vue front end, so the dump output, loader map, and components fit existing conventions instead of adding a parallel asset pipeline.
• You want a supported, uniform path for dynamic icons rather than a bespoke sprite-injection or fetch-an-SVG hack maintained by one person.
• The number of distinct icons rendered per session is modest, so per-icon requests amortize against caching rather than becoming a request storm.

Look elsewhere when:

• The icon set is fixed and known at build time. A bundler plugin, sprite sheet, or icon-font/subset approach gives better caching, zero runtime requests, and no fallback flicker. Adopting this package here buys complexity for a capability you do not need.
• Icons appear in critical above-the-fold UI (primary navigation, toolbars, loading states). Lazy per-icon fetches introduce waterfalls and layout shift; reserve this for secondary surfaces.
• You need server-side rendering with no client fetch for icons, strict CSP that forbids additional script/network loads, or offline-first behavior.
• There is no Laravel backend, or the front end is neither React nor Vue — you would be consuming the raw loader primitive and reimplementing the component layer, which erodes the buy argument.
• You need build-time icon subsetting, licensing enforcement, or per-icon telemetry that the package does not expose.

Open questions to resolve before committing: cache headers and long-term hashing on the per-icon modules; fallback dimensions and whether they match the final glyph to avoid layout shift (CLS); behavior on failed loads and whether errors are observable; accessibility of the fallback (does it announce anything, is it aria-hidden); and how icon names are validated, since a name originating from user or tenant data becomes a fetch target.

How to Pitch It (Stakeholders)

For executives: This release removes a blocker on customization. We can now let customers, tenants, or content authors choose icons at runtime — branding, navigation, dashboards — without shipping every icon in the product or funding a custom loader. The commercial value is in enabling white-label and personalization work already on the roadmap; the engineering cost is adoption and a small amount of fallback design, not new infrastructure. The main constraint to state plainly is that this is for secondary and content-driven UI, not the primary app chrome, so it does not replace our core icon strategy — it extends it.

For engineering: v0.2.0 adds runtime icon resolution. The dump emits one module per icon plus var/icons/loaders.js; loadIcon(loaders, name) fetches a single icon; UXLazyIcon wraps this for React and Vue with a fallback during load. The work on our side is convention, not construction: pick the fallback, confirm it reserves the right box to avoid layout shift, verify cache headers and hashing on the emitted modules, decide error behavior, and confirm icon names arriving from user or tenant data are validated before they become fetch targets. Budget a short spike on an existing dynamic-name surface before we generalize it.

Recommendation: Adopt for the specific class of surfaces where icon names come from data, contingent on the caching and fallback-dimension checks above. Keep static, critical-path iconography on the existing build-time approach.