Svg Inliner Laravel Package

Product Decisions This Supports

• Icon delivery strategy: inline <svg> vs. <img src> vs. sprite sheet vs. icon font. This package pushes you toward inlining, which is the only one of the four that lets CSS in the parent document style the SVG's internals. That single technical fact drives several downstream product decisions (theming, dark mode, hover/active states) that are expensive to reverse once an icon set ships as <img> tags or a font.
• Design-system and white-label theming. Inlined SVG inherits fill="currentColor" and CSS custom properties, so a tenant-branded or dark-mode theme becomes a CSS change rather than an asset re-export. If the roadmap includes multi-brand or per-customer theming, this is a gating technical choice, not an implementation detail.
• Performance budget for above-the-fold UI. Inlining removes a render-blocking request per icon. Worth quantifying: a header with eight icons is eight HTTP requests (or one sprite request) versus zero. Relevant for landing pages, checkout, and any surface with an LCP or INP target.
• Accessibility conformance. Inlined SVG can carry role="img", <title>, aria-hidden, and focusable="false" at the call site; <img> cannot be styled or annotated from the parent document. If the roadmap includes an accessibility audit or public-sector procurement, this reduces remediation scope.
• Build vs. buy vs. vendor. The real decision here is adopt vs. copy. The package is a thin utility (path resolution + file read + emit) with 1 star, 0 dependents, and a last release of November 2022. That is not a dependency decision; it is a "should we paste ~50 lines into our codebase" decision. Model it as a one-to-two-day internal utility, not a procurement item.
• CMS / editor-supplied SVG support. If the roadmap includes letting editors upload or paste SVG (logos, campaign artwork), you need runtime inlining plus sanitization. This package plausibly covers the first half only — see the adoption criteria below.

When to Consider This Package

Adopt (or, more likely, vendor) when:

• You are in a Laravel/Blade or plain PHP codebase and want to resolve an SVG by path at render time without introducing a frontend build step for that asset.
• Your icon set lives in the repo or a known assets directory, is authored by your own team, and is therefore trusted input. Inlining trusted SVG is a rendering convenience; inlining untrusted SVG is an XSS vector.
• You want a small, auditable surface: MIT-licensed, single-purpose, no transitive dependency tree to police. For a utility this size, "read the whole thing in ten minutes" is a genuine advantage over a larger icon package.
• You are prototyping and the alternative — wiring ?raw imports through Vite, or hand-rolling a Blade component — costs more than the package saves you this sprint.

Look elsewhere (or write it yourself) when:

• Sanitization is required. SVG is an XML document that can carry <script>, onload= handlers, and <foreignObject>. If any SVG crosses a trust boundary — uploads, CMS content, third-party logo packs — pair this with enshrined/svg-sanitize or sanitize at ingestion, and treat this package as the emitter only. Do not assume it sanitizes; verify before shipping.
• Maintenance signal matters. One star, zero dependents, no release since 2022. There is no community to catch a PHP 8.x deprecation or a path-traversal edge case. If your org's policy gates on maintenance activity, this fails it — vendor the code and own it.
• Your frontend build already solves this. Vite/Webpack ?raw imports or an svgo pipeline inline SVGs at build time with zero runtime cost and zero PHP dependency. If the icon set is static, build-time inlining is strictly better: no filesystem reads per request, no cache-key concerns.
• You are rendering SVG at volume. Inline emission inside a loop (e.g., a 200-row table of status icons) means repeated disk reads and repeated markup bytes with no compression benefit. You need a memoization layer or a sprite; this package gives you neither.
• You need sprites, symbol reuse, or <use> references. Different problem, different tool.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source utility for embedding SVG icons directly into server-rendered pages. The capability is real and it supports decisions we are already making — inline SVG is what makes dark mode, per-customer branding, and accessible icons cheap to implement instead of expensive to retrofit. But the package itself is a ~50-line helper with a single maintainer, one star, and no release since 2022. Recommendation: adopt the pattern, not the dependency. We copy the utility into our codebase under its MIT license, add tests and input sanitization, and own it outright. Cost is roughly one engineer-day; it removes a single-vendor risk while preserving the product benefits. This is a low-stakes, reversible decision — but it should be made deliberately rather than by a composer require that quietly becomes load-bearing.

For engineering: Treat this as a code sample, not a library. Vendor it, pin the PHP version in CI, wrap the file-resolution path so it cannot escape the assets root (path traversal), and add a sanitization step in front of any SVG that is not authored in-repo. Add a memoization cache so repeated icons in a loop do not re-hit disk. Write the three or four tests the package does not ship with. If the wrapper ends up larger than the original, that is the expected outcome and still cheaper than an unmaintained upstream.

For design and content: Inline SVG means icons respond to currentColor and CSS variables — ask for theming and state variations now, because switching from <img> to inline later touches every template.