Weave Code
Blade Pixelarticons Laravel Package
codeat3/blade-pixelarticons
Blade Pixelarticons brings the Pixelarticons set to Laravel as easy-to-use Blade components. Render crisp pixel-style SVG icons with a simple tag, customize size and color, and drop them into any Blade view without extra setup.
A package to easily make use of "Pixelarticons" in your Laravel Blade views.
Frequently asked questions about Blade Pixelarticons
- How do I install codeat3/blade-pixelarticons in a Laravel app?
- Install it with Composer using composer require codeat3/blade-pixelarticons. The package registers a Blade component namespace automatically, so there is no service provider to add manually and no configuration to publish before first use. It requires no build step, no JavaScript bundle, and no environment variables.
- How do I render a Pixelarticons icon in a Blade view?
- Use the registered component tag directly in any Blade template, for example <x-pixelarticons-{name} />. The name segment maps to the bundled SVG icon of the same name. Because it is a normal Blade component, it works anywhere Blade renders, including layouts, mail templates, and nested components.
- Can I change the size and color of the icons?
- Yes. The icons render as inline SVG through blade-ui-kit/blade-icons, so standard attributes such as width, height, and class pass through to the rendered markup. You can size and color them with utility classes or CSS, which keeps them consistent with the rest of your design system.
- Does this package support Laravel 13?
- Release 1.7.0 widened the illuminate/* constraint so the package can be installed on Laravel 13. That release contains no functional changes: the same glyphs, component names, and rendering path as before. Check the exact constraint in the release you pin to confirm whether it allows Laravel 11, 12, and 13 concurrently or requires Laravel 13 only.
- Can I change the Blade component prefix used for the icons?
- Yes, the component prefix is configurable, so you can avoid collisions with your own components or standardize on a house prefix. Decide the prefix once and record it in your frontend conventions document. After that it rarely needs revisiting.
- Do I need a build step or asset pipeline for production deploys?
- No. The package ships static SVGs that are inlined at render time, so there is no compilation or bundling required. For read-only or serverless filesystems, check whether your blade-icons version supports php artisan icons:cache and whether the package documents it, since that determines if a build-time caching step is needed.
- Are the rendered icons accessible for screen readers?
- The SVGs are static assets generated upstream, so accessibility behavior depends on the markup blade-icons produces and the attributes you pass. Review the rendered output for aria-hidden on decorative icons and confirm whether a title or aria-label can be supplied for meaningful ones. If not, a small wrapper component is the usual fix to meet your compliance bar.
- What are the alternatives to installing this package?
- The main alternative is publishing the handful of SVGs you actually use into resources and registering them with blade-ui-kit/blade-icons yourself. That removes the third-party dependency entirely and gives you full control over markup and accessibility. Other icon packages in the same family follow the identical pattern, so switching sets is a matter of changing the component prefix and names.
- Is codeat3/blade-pixelarticons risky to depend on in production?
- The blast radius is small: it is a leaf presentation dependency with no models, migrations, queues, middleware, or credentials, so it can be pinned or removed without an architecture review. The real risks are dependency hygiene and maintainer concentration, since it is one of many sibling icon packages from a single author with a small user base. The fallback is a contained refactor to local SVGs measured in hours, not a rewrite.
- Will it conflict with other icon packages or with blade-icons in Composer?
- The package is built on blade-ui-kit/blade-icons, so a Laravel major upgrade may force a blade-icons version that conflicts with other icon packages in your manifest. That resolution conflict is a more likely install failure than this package itself. Run composer why blade-ui-kit/blade-icons after upgrading and pin compatible versions across all icon sets.
Weaver
How can I help you explore Laravel packages today?