Blade Academicons Laravel Package

Product Decisions This Supports

• Feature scoping for researcher-facing surfaces becomes a fast "yes." Author profiles, publication bylines, CV/speaker pages, "find me on" link rows, citation and DOI blocks, and conference pages all need ORCID, Google Scholar, ResearchGate, arXiv, PubMed, and Semantic Scholar marks. This package converts that from a design-sourcing and asset-management task into a one-line Blade tag, so these features can be scoped and estimated without a design dependency. That is the core product leverage: it removes a blocker from a whole class of roadmap items.

• Build vs. buy resolves cleanly to "buy" (adopt). The alternative is sourcing, optimizing, accessibility-checking, licensing-reviewing, and versioning ~150 third-party brand glyphs ourselves — recurring cost with zero product differentiation. A thin MIT-licensed wrapper is the lower total-cost path, and the cost of reversing it later is trivial because adoption sits behind a template tag rather than a subsystem.

• Design-system consistency is the strategic argument, not the icons. If we already consume the codeat3/blade-* family (Font Awesome, Heroicons, Simple Icons), this extends the same <x-…> authoring convention instead of introducing a one-off SVG pipeline. That is a standards decision to make once, centrally, rather than per team or per feature — and it is the strongest reason to pick this specific package over an equivalent.

• Roadmap risk logging for the framework upgrade. Release 1.9.0 is a constraint-widening change adding Laravel 13 support (PR #15) with no API, config, or output changes. If a Laravel 12→13 upgrade sits on this cycle's roadmap, this dependency is confirmed non-blocking and should be recorded as such in the upgrade risk register so nobody re-litigates it mid-migration.

• Sets a UI convention we should capture once. Inline SVG per usage is free in a footer and wasteful in a 500-row table; the mitigation is an SVG <symbol> sprite or detail-page-only rendering. Similarly, this is a web-app tool, not an email tool — transactional and marketing mail must fall back to hosted PNGs or plain text links. Both are one-line guidelines in the UI conventions doc that prevent repeated debate.

• It does not unlock a differentiator — treat it as infrastructure hygiene. No end-user capability appears that we could not build otherwise. Budget minutes of PM attention, not roadmap attention. The decision to make is "adopt and pin," not "invest."

When to Consider This Package

Adopt when:

• The product renders academic identity or scholarly output this cycle — researcher profiles, publication metadata, author affiliation blocks, conference or speaker pages — and we would otherwise hand-roll or hotlink brand SVGs.
• We are on a Laravel version the current tag supports (1.9.0 widens the constraint through Laravel 13). Verify our PHP floor independently; it follows the host framework, not this package.
• We want icons as Blade components with pass-through attributes (class, sizing utilities, aria-label, fill="currentColor"), so theming, dark mode, and accessibility live in one place rather than scattered across raw markup.
• We already use the codeat3/blade-* family and value authoring-convention consistency over shaving one lockfile entry.
• We can commit to the small hygiene items: pin ^1.9, wrap the glyph in our own <x-academic-link> component so anchor semantics (rel="me noopener", target, accessible label, hover styles) and any future icon-pack swap stay a one-line change, and add view:clear / config:clear to the deploy runbook so a stale component prefix doesn't 500 pages that use an icon.

Look elsewhere or consciously skip when:

• Non-academic icons dominate. Academicons is a narrow, single-purpose set; it complements a general icon library and does not replace one.
• No researcher- or author-facing UI exists this cycle. This is speculative until the surface appears — revisit then rather than pre-installing.
• Dependency count or payload is tightly governed. Every icon package is another lockfile entry and another Laravel-major upgrade to track; adopt only if policy allows an exception request for a single-purpose package.
• We need build-time, tree-shaken SVG imports (Vite/React-style pipelines) rather than server-rendered Blade components. A sprite sheet or JS icon library fits that architecture better.
• Brand/trademark scrutiny is high. The marks are trademarks of ORCID, Google Scholar, ResearchGate, and others, and the icon set carries its own upstream license. Using them to link to a real profile is standard practice; using them as decoration or trust signals on a marketing page can imply an endorsement or partnership that does not exist. This needs a one-line written policy, not a legal project.
• Email is a delivery surface. Inline SVG is stripped or rendered inconsistently in Gmail and Outlook desktop.
• We need active feature development. This is a compatibility-and-icon-sync package: expect maintenance releases, not new capabilities. With one star, zero dependents, and a single primary contributor, plan for the possibility of abandonment — which the internal wrapper component already mitigates.

How to Pitch It (Stakeholders)

For executives: We evaluated codeat3/blade-academicons, a small MIT-licensed Laravel add-on that supplies standard academic logos — ORCID, Google Scholar, ResearchGate, PubMed, arXiv, and roughly 150 others — as ready-to-use UI components. It is a low-cost, low-risk adopt that removes design and engineering effort from any researcher- or author-facing surface on our roadmap: profiles, publication bylines, speaker pages, and citation blocks can ship without a design dependency or a bespoke asset pipeline. Release 1.9.0 is a maintenance update adding Laravel 13 compatibility — no breaking changes, no migration work, no user-facing impact — so adopting it also modestly de-risks our framework upgrade path. The cost of reversing the decision later is essentially zero, because adoption lives behind a single template tag. Recommendation: adopt, pin to ^1.9, and fold it into the routine Laravel-major upgrade sweep. The only diligence item is confirming the brand-mark licensing and usage guidelines suit our context — specifically that we use these logos to link to real profiles, not as decorative trust signals.

For engineering: 1.9.0 is a single change — Laravel 13 compatibility (PR #15) — layered on 1.8.0, with no API, config, or output changes, so it is a safe composer update on an existing install. The package is a thin wrapper that publishes the Academicons SVGs and registers Blade components under a configurable prefix (default academicons); runtime surface is trivial, with no service-provider configuration to reason about, no database, queue, cache, or external API dependency, and no CSP implications since inline <svg> is DOM, not script. Install with composer require codeat3/blade-academicons, publish the config only if we need a custom prefix, and use <x-academicons-orcid class="h-5 w-5" /> directly. Two operational notes: wrap the glyph in our own <x-academic-link> component so anchor semantics (rel="me noopener", target, accessible label, hover styles) and fill="currentColor" live in one place and an icon-pack swap stays a one-line change — store un-prefixed slugs in data and let the prefix stay a config concern via <x-dynamic-component>; and remember component registration is cached, so after a config change or composer update, run view:clear and config:clear, or a stale prefix will 500 every page using an icon. An unknown slug throws a Blade "unable to locate component" error, so validate slugs on ingest. If the upstream Academicons CSS/font (<i class="ai ai-orcid">) is present anywhere, remove it in the same change — leaving the markup behind renders nothing once the CSS is gone, and leaving the CSS ships a webfont we no longer need. Verify our PHP version satisfies Laravel 13's floor before bumping the framework. Residual risk is version alignment for teams on older Laravel, plus the usual dependency-hygiene tracking each Laravel major.