Blade Maki Icons Laravel Package

Product Decisions This Supports

• Build vs. buy for commodity assets — resolved on cost, not on features. The real alternatives are hand-maintained SVG partials in the repo, an internally owned Blade icon library, or a paid icon subscription. All three carry recurring cost — upkeep, PR review, licence review — for artwork that is genuinely a commodity. codeat3/blade-maki-icons collapses that to a single pinned composer require. Building only wins if you need bespoke or brand-restyled glyphs, which a fixed open-source set cannot provide.

• A decision about how icons ship, not a feature bet. This is infrastructure: versioned with the app, server-rendered, reviewed in pull requests, deployed with the release. Frame it in roadmap reviews as design-system hygiene with a maintenance-cost payoff rather than a headline capability — it will not move a user metric, and it should not be sold as if it will.

• Unblocks map, geolocation, and logistics surfaces. Concrete areas this accelerates: store and venue locators, delivery and fleet-tracking dashboards, POI pickers, travel and hospitality interfaces, and any map legend or marker taxonomy. If the roadmap carries a "find a location near me" surface, this is a same-sprint dependency rather than a design-project blocker.

• Roadmap input: framework-upgrade readiness. Release 1.10.0 exists for exactly one reason — widening the constraint to permit Laravel 13. The PM-relevant takeaway is not "new icons," it is that this dependency would otherwise have pinned the platform at Composer resolution. Track it in the upgrade workstream as an unblocker, and treat future maintainer lag as a schedule risk to the platform roadmap, not a cosmetic nit.

• A dependency-register entry, not an architecture-review gate. Blast radius is deliberately small: no routes, migrations, config, queues, or background services. If it breaks, an icon renders blank — visibly, harmlessly, and not on a checkout path. The exit (vendor the SVG directory, or fork the thin wrapper) is measured in days. That asymmetry argues for permissive adoption with light governance.

• A forcing function for icon consolidation. Adopting this raises one question the roadmap should answer once: how many icon sets does the product ship today? If the answer is more than two, the actual decision is whether Maki becomes the sanctioned vocabulary for map and POI contexts — or becomes a third parallel set design has to reconcile.

• Scope discipline as the real constraint. Maki is Mapbox-originated and map/POI-oriented; it is not a general UI icon system. Approving it for navigation, forms, and media controls guarantees a second icon dependency within a quarter — the exact fragmentation the adoption was meant to prevent.

When to Consider This Package

Adopt when:

• The product genuinely renders geospatial or POI UI, and the team wants a coherent, licence-clear icon vocabulary for it rather than picking glyphs ad hoc.
• The stack is Laravel with a Blade rendering surface — including Livewire apps, or Inertia apps that still render Blade views — and the team prefers server-rendered components over adding a JS icon library and its build-step weight.
• Design has approved, or can approve, the Maki visual language. Consistency across the map surface is the value; bespoke artistry is explicitly out of scope.
• Icons should version and deploy with the application, so a glyph change travels through code review and the release pipeline instead of arriving as an untracked design-tool export.
• You are retiring an existing chore — engineers hand-editing SVG paths or maintaining a sprite sheet. Here the package is a net reduction in owned code.
• You are executing a Laravel major upgrade and need to confirm this dependency is not the constraint pinning the framework.

Look elsewhere when:

• The visual language requires brand-specific iconography. Maki is a fixed set: size, colour, and pass-through attributes are adjustable; the drawings are not.
• The frontend is a decoupled SPA with no Blade layer. A JavaScript icon package is the correct fit; extracting icons server-side for React or Vue solves the wrong problem.
• You need a general-purpose UI icon system. Maki is map/POI-oriented, and used as the universal set it leaves obvious gaps that push teams back to ad-hoc SVGs.
• Policy requires vendor SLAs, per-dependency security review, or commercial support. This is a community package from a single maintainer, generated from an upstream open-source set.
• Payload weight is a hard constraint and a tree-shaken sprite would beat per-component rendering. Measure icon-heavy screens rather than assuming — and check whether an icon-caching/optimisation command is available to mitigate.
• There is no near-term map or location roadmap. Adopting an icon set ahead of the feature that justifies it is inventory, not capability.

Questions to settle before the decision meeting:

1. Do we have a committed map/POI surface today, or is this speculative adoption that produces a redundant second icon library in six months?
2. Is the Laravel 13 constraint widening actually usable for us — does our PHP floor satisfy it, and does the resolved graph contain another package still pinning illuminate/support to ^11/^12?
3. Who owns icon-set standardisation, and does the maki prefix — or our internal wrapper name — collide with an existing design-system namespace?
4. What is our documented fallback if upstream support lapses — vendored SVGs or a fork? "We'd figure it out" is not a fallback.
5. Is this in the dependency register with a named owner and a review cadence, or is it being adopted informally because it is cheap?

How to Pitch It (Stakeholders)

To executives. This is a near-zero-cost, low-risk adoption that retires an ongoing engineering chore — hand-managing map and location icons — in favour of a versioned, open-source set rendered directly from our templates. No licence fee, no vendor contract, no lock-in: the icons are open source and the wrapper is thin enough to fork or replace within days. Timing matters more than the feature. Release 1.10.0 is a maintenance-only update adding Laravel 13 support, which means this dependency stays current with our platform rather than becoming the thing that blocks our next framework upgrade. Recommendation: approve adoption for map and location surfaces, and approve the 1.10.0 bump as part of the platform-upgrade workstream. No budget impact, no headcount impact.

To engineering. Version 1.10.0 is a compatibility release with a single change — widening the framework constraint to permit Laravel 13. No API changes, no renamed components, no removed icons, no deprecations. From 1.9.0 this is a routine composer update; for anyone blocked on Laravel 13 it is the unblocker, not an optional bump. Architecturally the package is inert: a service provider registering Blade components backed by static SVG data, with no routes, migrations, config, or runtime services. Three guardrails. First, pin the version in composer.json — the icon set itself changes between releases, so an unpinned minor bump can silently alter glyphs in shipped UI. Second, wrap the vendor prefix in one internal component that owns sizing, colour, accessibility, and fallback, so a future swap is one file rather than a codebase-wide find-and-replace; land the wrapper before adoption spreads, since retrofitting an abstraction negates the benefit. Third, add snapshot tests on icon-heavy pages and a view-compile check in CI — together they catch both silent visual drift and component-registration collisions. When sequencing the Laravel 13 upgrade, bump this package in the same change set and run a dry-run resolve first; a single laggard constraint elsewhere in the graph defeats the release regardless of what this package permits. Confirm PHP version parity with Laravel 13 before committing to a date.

To design. You get a consistent, licence-clear glyph vocabulary for map and POI surfaces, delivered through the same component system as the rest of the UI, with sizing and colour controlled by your existing utility classes. The trade-off to accept explicitly is that Maki is a fixed third-party set — the drawings are not editable, only the container is. If a future brand refresh requires bespoke map iconography, that is a separate design investment, and the internal wrapper component keeps swapping the underlying set a contained change. The one thing design must own is scope: Maki stays the sanctioned set for map and location contexts, and we do not let it drift into a general UI icon role where it will under-deliver.