- What does filafly/phosphor-icon-replacement actually do?
- It is a Filament plugin that replaces the default Filament icons with the Phosphor icon set. The swap happens across Filament UI components, so you get a cleaner, more consistent admin panel without writing custom markup. Architecturally it is a view-layer-only dependency: no models, migrations, routes, or service boundaries are involved.
- Is filafly/phosphor-icon-replacement still maintained?
- No. Version 1.0.2 is a patch release whose only change is marked as a deprecated package under FIL-29. That means no security patches, no tracking of Laravel 11 or 12 view-component changes, and no PHP 8.4+ fixes. Treat it as a package to exit rather than upgrade.
- Should I install this package in a new Laravel project?
- You should not adopt it for new work. Because the maintainer has explicitly deprecated it, you would be adding a dependency with no forward path on day one. Pick a maintained icon package or a direct SVG sprite approach instead, and confirm first whether a named successor exists.
- Which Laravel and Filament versions does it support?
- Support depends on the Composer constraints in the released version, so check the package's composer.json against your installed Filament version. Since deprecation means no further compatibility work, a future Laravel upgrade may fail to resolve or force a dependency override. Pin the exact version in composer.json if you are already using it.
- How do I install it with Composer?
- Run composer require filafly/phosphor-icon-replacement, then publish any config or asset stubs if the package provides them. After that you swap or alias the icon component references used in your Blade templates. No routing, persistence, queue, or auth changes are required, which is why adoption effort is low.
- What is the safest way to remove it from an existing app?
- Treat it as a removal project, not an upgrade. Freeze the currently pinned version, inventory every usage with grep across resources/views plus any config-driven or database-driven icon name strings, then introduce the successor alongside it and migrate views in batches. Compare rendered output before deleting the package, its config, and any published vendor assets.
- What are the risks of leaving it installed?
- The main risk is silent failure: icon replacements are cosmetic, so a broken swap shows up as wrong rendered output rather than an exception thrown in production. You also get dependency drift as Composer resolution tightens, no PHP or Laravel fixes, and a likely flag in composer audit or SBOM checks where organisations block deprecated packages.
- Is there an official successor or replacement package?
- That is not confirmed in the package metadata. The FIL-29 reference suggests an internal Filament ticket, so check the maintainer's README and linked PR to see whether the intent is use this instead or the feature was folded into core. If no successor exists, plan for an alternative icon package or SVG sprites.
- Does it affect performance or require asset compilation?
- It is a view-layer shim, so the runtime cost is negligible compared to the Blade and CSS work Filament already does. If you ship icons as compiled CSS or SVG sprites through Vite or npm, those build artifacts may need regenerating when you swap the source. Check whether your pipeline caches icon output.
- How do I test that the icon replacement still works after a swap?
- Use visual regression testing rather than unit tests. Screenshot diffs in CI across representative admin pages will catch icons that silently fail to render, which assertions usually miss. Also verify dynamic or string-based icon resolution paths, since those are harder to catch with a simple grep.