Fontawesome Picker Bundle Laravel Package

Getting Started

First, resolve the framework mismatch. This is a Symfony 2+ bundle, not a Laravel package — there is no service provider, no config/app.php entry, and no php artisan vendor:publish. Composer will install it, but Laravel's container will not wire any of it. Before writing a line of code, decide whether you are (a) actually in a Symfony app, or (b) a Laravel dev who wants the picker UI (the JS/CSS asset), not the bundle.

If you are on Symfony:

1. composer require redking/fontawesome-picker-bundle
2. Register it in app/AppKernel.php (Symfony 2/3) or config/bundles.php (Symfony 4+): new Redking\FontAwesomePickerBundle\FontAwesomePickerBundle()
3. Publish the assets: php bin/console assets:install --symlink (or webpack/encore copy them)
4. Confirm the Font Awesome CSS is loaded in your base layout

Where to look first: the *Bundle.php class (tells you what it registers), the form type class under Form/Type/ (the public API you actually call), and Resources/public/ (the real value — the underlying jQuery/Font Awesome picker JS). The bundle is a thin wrapper; the picker plugin is the substance.

First use case: an icon field on an entity form. In Symfony it is roughly:

$builder->add('icon', FontAwesomePickerType::class);

If you are on Laravel (the likely reality given this assessment): skip the Composer install. Read the Resources/public JS/CSS directly, vendor those two or three files into resources/js/resources/css, and reimplement the Symfony form type as a Blade partial + a validation rule. Do not try to bootstrap the Symfony kernel inside Laravel.

Implementation Patterns

Symfony form type. The idiomatic pattern is to register the picker as a reusable form type, then render it wherever an icon needs selecting. Compose it into larger forms rather than hand-rolling an <input> each time.

Store the icon class string, not an ID. The picker's output is a Font Awesome class (e.g. fa-solid fa-star). Persist that string in a varchar column. Decouple it from the picker so the data survives if you swap the UI.

Laravel port — Blade component. Mirror the form type with a component:

<x-icon-picker name="icon" :value="old('icon', $model->icon ?? null)" />

Keep the JS initialization in the component and pass the current value through so edit forms pre-select the right icon. This is the cleanest way to "leverage the package" without depending on it.

Validation. Both frameworks benefit from a rule that pins valid output:

'icon' => ['nullable', 'string', 'regex:/^fa[srlb]? fa-[a-z0-9-]+$/'],

Adjust the prefix to your Font Awesome major version (FA4 uses bare fa fa-*; FA5/6 uses style prefixes). Validating the class string also protects against arbitrary HTML sneaking through the field.

Data-driven rendering. Wherever you display the icon, render it through one helper/partial so a future FA upgrade is a one-file change:

<i class="{{ $icon }}"></i>

Reuse the picker as a plain widget. The most portable pattern is to treat the bundle purely as a source for the JS picker and wire it manually to any input — Symfony, Laravel, or a static page. This sidesteps the framework question entirely and is what most people actually want from packages like this.

Asset pipeline. On Symfony, assets:install. On Laravel, copy into your Vite/Mix source and import the plugin before your initializer. Do not reference files from vendor/ at runtime — that path is fragile across deploys.

Gotchas and Tips

• It is not a Laravel package. The single biggest pitfall. No service provider, no facade, no config merge, no Blade views. Any tutorial telling you to composer require it in Laravel and "just use it" is wrong.
• Effectively abandoned. Last release 2017-11-30, 2 stars, 0 dependents, score 0.14. Treat it as sample code, not a maintained dependency. Expect Symfony 2/3-era PHP constraints (>=5.x) that will fight modern Composer if you try to install it in a new project.
• Font Awesome version drift is the real breakage. The bundle shipped against FA4 icon names. FA5/6 renamed and prefixed everything (fa fa-* → fa-solid fa-*, icons removed, brands split out). The picker's icon list and your rendered markup must be on the same major version or you get empty boxes.
• Assets silently 404. The picker renders but does nothing if assets:install was skipped or the Font Awesome CSS isn't on the page. First debugging step: check the network tab for the picker JS/CSS and FA webfonts.
• Form theming. If the widget renders unstyled or broken inside a custom form theme, the bundle's block may not be extended. Override the form theme block rather than patching vendor files.
• Config quirks. Symfony 4+ apps must use config/bundles.php, not AppKernel; mixing the two means the bundle never boots and the form type is "unknown."
• CSRF / JS conflicts. The picker attaches to inputs on DOM ready; if you render forms dynamically (Turbo, Livewire, AJAX), re-initialize the picker after morphing, or the widget binds to a detached node.
• Extension points worth using: wrap the Symfony form type in your own App\Form\Type\IconPickerType so an FA upgrade or a picker swap is contained; in Laravel, wrap the JS in a single Blade component. Either way, don't call the bundle's classes directly from dozens of places.
• Debugging checklist: bundle registered? assets installed? FA CSS loaded? correct FA major version? input name matches what the JS expects? That sequence resolves nearly every "picker doesn't open" report.
• License is fine (MIT). The blocker is maintenance and framework fit, not legal — you may freely fork the JS and reimplement. Given the zero-dependents status, forking the picker asset into your own resources/ is a reasonable, low-risk move.