Blade Carbon Icons Laravel Package

Technical Evaluation

Decision framing: whether to standardize codeat3/blade-carbon-icons as the canonical icon source for Blade-rendered Laravel surfaces, and when to take the 2.39.0 bump. This is a commodity, presentation-layer dependency decision — timebox it, pin it, and keep the exit cheap. It is not a platform or architecture decision.

Architecture fit

• Pure view layer: SVG assets plus a service provider that registers <x-carbon-* /> Blade components. No migrations, routes, config publishing, queues, event listeners, or persisted state. Blast radius is confined to template rendering; it cannot corrupt data or hold runtime state.
• Fits Blade-, Livewire-, and admin/back-office-style applications where markup is server-rendered. Does not fit Inertia/React/Vue front ends that never render Blade, or API-only services.
• Deliberate visual commitment, not a neutral default: Carbon is IBM's geometric, utilitarian iconography and reads as "enterprise / B2B / data-dense." Get design sign-off before it becomes house style, because swapping icon languages later is a template-wide edit.
• Redundancy risk: running this alongside Heroicons, Blade UI Kit, or Font Awesome buys nothing and doubles icon-governance surface. One canonical set, documented, or none.
• Zero-JS, no CDN, no build step is the real architectural differentiator — it satisfies strict CSP, air-gapped/on-prem, and email/PDF rendering constraints without a separate asset pipeline.

Integration feasibility

• composer require codeat3/blade-carbon-icons with auto-discovery is a one-line install. The actual effort is substitution: replacing inline SVGs, <i> font tags, and <img> sprites across templates, and verifying every icon name exists in the Carbon catalogue.
• Sizing, color, and accessibility conventions (class, size, aria-hidden on decorative icons, title/role on meaningful ones) are per-team choices today. Without a house convention set early, each feature team reinvents it and usage sprawls.

Technical risk

Key questions to close before deciding

1. Is any app in the portfolio on Laravel 13 today? If not, 2.39.0 is a no-op and should ride an existing framework bump rather than trigger its own cycle.
2. Does the package's PHP/Laravel constraint matrix install cleanly on every target app without --ignore-platform-reqs?
3. How many glyphs do we actually use? Under ~20, an internal SVG partial is cheaper than a dependency plus a governance item.
4. What is the support position? There is none — confirm the business accepts a community-supported, single-maintainer dependency for UI chrome.
5. What is the exit artifact — a vendored SVG fork or a swap to a sibling blade-* package — and who owns it?

Confidence: medium. Assessed from release notes and package description only; composer.json, icon count, and component signatures were not inspected.

Integration Approach

Stack fit

• Target: server-rendered Laravel with Blade as the primary view layer, including Livewire and admin/back-office tooling. Explicitly out of scope: SPAs, mobile clients, and anything where the bundler should own icon assets.
• Pairs naturally with a design-system decision: if Carbon is the reference visual language, this package is the cheapest possible implementation of it.

Migration path (pilot-scoped)

1. Feature branch; pin 2.39.0 exactly, not ^2.0.
2. Build a smoke-test route rendering a representative icon sample across the sizes and filled/outline variants the product actually uses.
3. Replace markup template by template, highest-traffic views first; keep legacy markup until visual parity is signed off.
4. Only after parity: delete the superseded icon font/sprite, its CSS, and any CDN references.
5. Publish a one-page internal convention (canonical set, sizing scale, accessibility rules, where the catalogue lives) before a second team adopts.

Compatibility

• 2.38.x is effectively the last line for pre-13 constraints; 2.39.x is the line for Laravel 13. Pin per app rather than floating the minor, so a future major or a dropped-version release cannot break a build unannounced.
• In a monorepo or multi-app portfolio, one app on an older Laravel blocks a portfolio-wide bump. Inventory versions first; pin stragglers and log them as dated technical debt.

Sequencing

• Treat 2.39.0 as a maintenance bump, not a project: no feature work, no user-visible change, no release communication.
• Sequence it with the Laravel 13 upgrade, not ahead of it — one test cycle instead of two. If no 13 upgrade is on the roadmap in the next two quarters, record the version and defer.
• Effort: <1 day for install plus smoke test; 1–3 days for broad template substitution in a mid-size app. Pilot one product, review after one release cycle, then decide on portfolio standardization.

Operational Impact

Maintenance

• Effectively zero run-cost: no config to drift, no cron, no state, no data. Releases are infrequent and optional.
• The one genuine obligation is dependency hygiene — staying on a release line that supports the current Laravel major. A stale icon package becomes an upgrade blocker at the worst possible moment, which is precisely what 2.39.0 pre-empts.
• Add it to the periodic dependency-review list with a named owner and a recorded fork/swap contingency in the risk register.

Support

• Community-supported: no SLA, no indemnification, no vendor escalation path. Internal knowledge will be thin — realistically one or two engineers understand the component registration and naming convention.
• Mitigate by documenting the convention and the exit path, not by staffing a support rota. Treat tickets as ordinary Blade work.

Scaling

• Scales with the number of rendered icons in a response, not with request volume or data size; it is a view-compile concern, not a throughput concern. Icon-heavy list and dashboard views are the only place worth profiling.
• Component registration cost is paid at view-cache compile, i.e. on deploys, not per request once cached. Measure cold-deploy compile time on the largest app before broad rollout.
• Not a scaling lever in either direction: adopting it neither improves nor degrades capacity planning.

Failure modes and their detection

• Maintainer stops tracking Laravel majors → surfaces as a blocked framework upgrade. Detection: dependency-review cadence. Response: swap to a sibling blade-* package or vendor the SVGs (1–3 days).
• Upstream icon renamed or removed in a bump → surfaces as a rendered-blank or component-not-found error. Detection: the smoke-test route in CI. Response: pin back, then rename references deliberately.
• Visual/sizing drift versus the set being replaced → no automated check catches this. Detection: design sign-off in the pilot only. Response: fix the house convention, not the package.
• Two icon libraries in production simultaneously → surfaces as duplicated bundles and inconsistent UI. Detection: design review. Response: finish the substitution or revert; do not park it half-done.
• Constraint mismatch in a monorepo app → surfaces at composer update. Detection: version inventory before the bump. Response: pin that app and log the debt.

Ramp-up

• Hours for a Laravel-comfortable engineer: the syntax is a single Blade component tag, and the package is auto-discovered. The learning curve is entirely in the house convention (sizing, color, accessibility), not the dependency.
• Onboarding requirement: one page in the team wiki plus a link to the Carbon catalogue. No training session, no runbook, no on-call implication.
• Decision checkpoint after one release cycle: did the maintainer ship for the current Laravel major? If yes, standardize the pilot product and consider the next. If no, execute the recorded exit and move on.