Blade Icons Packages Collection Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for brand/technology iconography. Any "Built with Laravel", "Integrations", "Works with", or compatibility-badge surface needs vendor logos. The real alternatives are commissioning bespoke SVGs, hotlinking/scraping vendor press kits, or adopting a Blade-native set. This package collapses option three into roughly an afternoon of work for teams already on blade-ui-kit/blade-icons, and removes a recurring design-handoff cost from marketing and docs backlogs.
• Roadmap sequencing for logo-heavy surfaces. Landing pages, pricing and integrations grids, docs "compatible with" badges, admin dashboards listing connected tools, and changelog/status pages all consume the same asset type. If any of these are on the roadmap, the icon source is a prerequisite decision — and this is a cheap way to unblock it without a design sprint.
• Standardisation, not just sourcing. It supports the decision to settle on one strategy — blade-icons as renderer, a small explicitly pinned set of icon packs as content — instead of the usual drift into scattered <img> tags, mixed SVG formats, and inconsistent sizing across templates.
• Trademark and licensing governance. The MIT licence covers the code, not the marks. Bundling third-party logos is a policy decision: do we need per-vendor permission, who handles a takedown or brand refresh, and who owns that list? The package forces this conversation early and cheaply — before logos are sprayed across a public marketing site.
• Dependency posture: snapshot vs. infrastructure. With 2 stars, 0 dependents, and an overall score of 0.01 against an opportunity score of ~13, the honest framing is a curated asset catalogue, not maintained infrastructure. There is also genuine scope ambiguity — this may be a README index rather than an installable metapackage — which is itself a PM decision to resolve before any ticket is written. Treat it as a research artifact and decision input; pin or vendor anything you actually ship.

When to Consider This Package

Consider it when:

• You are on Laravel + Blade (or Livewire/Inertia) and already use, or are about to adopt, blade-ui-kit/blade-icons.
• You need recognisable logos of PHP, JavaScript, and developer-tool packages — frameworks, languages, databases, CI tools — for a marketing page, docs site, or integrations dashboard.
• You want zero runtime cost and zero design-tool dependency: static, version-controlled SVGs compiled into views, styled with standard attributes (size, class, colour).
• The surface is low-stakes, internal, or marketing-adjacent, where a missing or slightly dated logo is cosmetic, not an outage.
• You want to skip the asset-pipeline yak-shave — no CDN, no image optimisation step, no designer ticket per logo.

Look elsewhere when:

• You need a general-purpose UI icon set (navigation, actions, states). This is brand/logo iconography; pair it with Heroicons, Phosphor, Tabler, or Lucide for interface icons.
• The logo you need isn't in the set, or brand guidelines changed and you need the current, officially sanctioned mark. Prefer vendor press kits or a maintained source like Simple Icons; treat this bundle as a snapshot.
• You need maintenance guarantees, SLAs, or responsive upstream. Two stars and zero dependents means no crowd-sourced bug discovery and an apparent bus factor of one — you would be the first to hit any breakage.
• You are not on Laravel/Blade — the components are Blade-specific and the value evaporates outside that stack.
• Your legal or brand team requires documented per-logo provenance and current usage terms. Bundles obscure provenance; a hand-curated set with a licence/attribution register is safer for a high-visibility public site.
• Accessibility is load-bearing. Decorative logos should be aria-hidden; meaningful ones need alt text or adjacent labels. You own that work regardless of the package.
• Framework-upgrade cadence is tight. Bundled sets carry independent PHP/Laravel/blade-icons constraints; resolution conflicts can gate a Laravel upgrade behind a curator's release schedule.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed catalogue of ready-made technology and package logos that plugs into the Laravel frontend stack we already use. It lets us ship "Built with", integrations, and documentation pages without commissioning bespoke artwork or chasing vendor brand assets, and it adds no runtime cost — the icons are static files compiled into the page. The realistic risks are not technical: they are brand and trademark usage (the MIT licence covers code, not logos) and staleness (the project has minimal community adoption, so treat it as a snapshot we pin rather than infrastructure we depend on). Position it as cost avoidance for a visible but non-critical slice of UI, gated by a short legal/brand review — and note that even in the worst case we consume it as a shortlist and composer require the two or three upstream icon packs we choose ourselves.

To engineering: It's a blade-icons-compatible logo set for marketing and docs surfaces — not a UI icon library and not a rendering engine; blade-ui-kit/blade-icons is the stable substrate. First task is to confirm what it actually is: a real metapackage with require entries, or a README index. If installable, adoption is one composer require plus auto-discovery and a component tag in any Blade template. Before committing: pin the version explicitly, check component-name collisions against other registered sets and apply a prefix convention, confirm the PHP/Laravel floor matches ours, and measure vendor/ delta plus view:cache wall time in a spike branch. Register only the sets the design system actually consumes — "install everything" is the anti-pattern, since autoloader classmap, container image size, and view-cache time all scale per set. If the logos are public-facing, vendor the SVGs into our own repo so an abandoned upstream or a re-vendor:publish on upgrade can't silently change or clobber them, and keep a short docs/icons.md recording which logos we ship, why, and where they came from — that list doubles as our response plan when a vendor asks us to update or remove a mark.