Weave Code
Blade Icons Packages Collection Laravel Package
codeat3/blade-icons-packages-collection
A Laravel Blade package that bundles icon sets from popular icon packages into one collection, letting you render any included icon with a simple Blade component or directive without installing each set separately.
A curated list of blade-icons packages
Frequently asked questions about Blade Icons Packages Collection
- Is codeat3/blade-icons-packages-collection a real Composer metapackage or just a list of links?
- Treat it as a curated catalog first. It is best described as a manifest and documentation artifact; whether an install pulls in require entries for icon sets depends on the composer.json you actually receive. Run composer show codeat3/blade-icons-packages-collection after requiring it to see which packages it pulls in. If it ships no require entries, there is nothing to install and you pick the upstream sets yourself. Resolve this distinction before writing any tickets, because it changes the effort by an order of magnitude.
- How do I install blade-icons-packages-collection in a Laravel application?
- If it is a true metapackage, integration is a single composer require codeat3/blade-icons-packages-collection with Laravel package auto-discovery, plus an optional config stub to publish. In the catalog reading there is no install step at all: you choose an upstream blade-icons set and require that directly. Either way the real work is selection and licence review, not engineering. Dry-run it on a branch before committing, since installation is an afternoon at most and often a no-op.
- Which Laravel and PHP versions does this package support?
- There is no reliable published compatibility matrix at this maturity level, so read the composer.json constraints and the release history yourself. Each bundled set carries its own independent PHP, Laravel, and blade-icons constraints, so the effective floor is the strictest one in the bundle. Plan on PHP 8.1+ and Laravel 9+ as a sensible baseline and confirm the current blade-icons major is supported. If you maintain an older Laravel branch, pin per branch or skip the metapackage entirely.
- Does installing it register every icon set globally, or can I opt in per set?
- This is the question to answer before installing: does the package register every set globally, or can you enable sets one at a time? Global registration means every icon set lands in your autoloader, view paths, and view:cache output whether you use it or not. Prefer requiring individual sets directly if per-set opt-in is not available. Confirm the behaviour by diffing the registered Blade components before and after install.
- How is this different from blade-ui-kit/blade-icons?
- blade-ui-kit/blade-icons is the rendering substrate: it registers SVG sets as Blade components behind per-set prefixes. This repository sits above that layer and points you at which sets to adopt; it does not render anything itself in the catalog reading. If you already know which set you want, require blade-icons and that single set directly. Alternatives are simply picking individual icon packs, or using a dedicated Font Awesome or Heroicons Blade package on its own.
- Are the bundled icon set licences safe for commercial and client work?
- Every set carries its own licence, and MIT, CC-BY, OFL, and the Font Awesome free versus Pro split all appear in this space. A bundle obscures provenance, so audit each set you actually ship and record attribution requirements before release. Watch specifically for CC-BY attribution obligations and any Pro assets that require a paid seat. Do this at selection time, not when a vendor legal notice or review catches it later.
- Will adding icon sets bloat vendor and slow down view:cache and CI?
- Yes, if you register many sets. Icon sets are thousands of static SVGs, and vendor size, container image size, the autoloader classmap, and view:cache time all grow with each registered set. That cost is paid on every CI run and every deploy, so keep the bundle minimal and require only the sets your design system actually consumes.
- How do I avoid prefix collisions between icon sets like home, user, and search?
- blade-icons registers each set behind a prefix, so duplicate names like home, user, or search across two sets are a configuration problem rather than a package bug. Decide naming conventions per set and keep component names stable in your own design system wrapper. Render a handful of icons from each set to confirm the expected prefix resolves.
- How should I test Blade icon components in CI and production?
- Assert the components you actually use render: a feature test that outputs a few icons through Blade and checks the SVG is present catches registration and prefix problems early. Keep view:cache in the pipeline so a broken icon path fails the build rather than production. If the package turns out to be a catalog only, there is nothing of its own to test, so test the upstream sets you installed.
- Is this package actively maintained, and is it safe for production?
- The repository shows very low signal: two stars, zero dependents, and no production validation behind it. Treat every README claim as unverified until you dry-run it, and ask who curates it, on what cadence, and against what inclusion criteria. The bus factor matters because a metapackage's release hygiene can gate your framework upgrade cadence. Frame it as a research artifact that accelerates a decision, not as infrastructure the product is built on.
Weaver
How can I help you explore Laravel packages today?