dryven/faviconator
Dryven Faviconator is a Laravel package for generating and managing favicons for your application. It helps you produce the icon files and markup needed to display proper favicons across browsers and devices, simplifying a typically tedious setup.
Minimal steps
composer require dryven/faviconator — for v2.0.0 confirm your PHP and Laravel versions against the package's composer.json before pulling it in (composer why-not dryven/faviconator 2.0.0 is the fastest way to see what's blocking).php artisan vendor:publish --tag=faviconator-config (check php artisan vendor:publish listing output — the tag name is the one thing most likely to have shifted in a major).config/faviconator.php expects it — this package's whole model is one source image fanning out into the favicon/icon set.php artisan faviconator:generate) and verify files land in your configured output path.<head> — usually via the package's Blade component/directive — and load a page to confirm the link rel="icon" tags render.Where to look first
config/faviconator.php after publishing — it is the contract for source path, output path, sizes, and view. Read it end-to-end before touching anything else.src/ for the service provider (to see what's registered: command, Blade component, view namespace) and the command class (to see real defaults and error messages).vendor/dryven/faviconator/CHANGELOG.md and the v1.3.1...v2.0.0 compare diff — see Gotchas; v2.0.0 shipped with a placeholder body, so the diff is the changelog.First use case
The bread-and-butter flow: one brand asset in, a complete icon set out, generated as a build artifact rather than committed by hand. Wire the generate command into your deploy script so public/favicon.ico, apple-touch-icon.png, and the rest are never stale relative to the source image.
Generate at build/deploy time, not at request time
Treat icon generation as a build step. Add it to your deploy pipeline or a Composer script:
"scripts": {
"post-deploy": ["@php artisan faviconator:generate --ansi"]
}
This keeps intervention/image (a likely transitive dependency) out of the hot path and makes the output reproducible. Don't call generation from a service provider's boot() — it will run on every request in dev and mask real failures.
Commit the output, not the dependency on generation
For most apps the generated icon set changes a handful of times a year. A common, pragmatic split: run generation locally, commit the generated files under public/, and keep the package as a dev-oriented tool. If you go this route, add a CI check that regenerating produces no diff — that catches "someone changed the source image but forgot to regenerate."
Reference assets through the package's view, then override it
Use the shipped Blade component/directive in resources/views/layouts/app.blade.php. When you need extra tags (mask-icon, theme-color, a manifest link), publish and override the package view rather than hand-writing duplicate <link> tags — hand-written tags and the package's tags will drift, and you'll get doubled rel="icon" entries that browsers resolve unpredictably.
Per-environment configuration
Point output_path/source path at env-driven values so local dev can use a placeholder mark while production uses the real one. Keep the sizes list in config under version control rather than overriding at runtime; the generated set is a contract with browsers.
Multi-tenant / white-label
Because generation is config-driven, a multi-tenant setup can loop the command with --env-style overrides or by swapping config at runtime before invoking the command in a job. Scope output per tenant directory and clear the config between iterations (config()->set(...)) — config is not request-isolated inside a long-running worker.
Testing
Assert on the rendered <head> (the presence of the expected link tags) rather than on binary image output. For the generation path, assert files exist and are non-zero after running the command in a test using Storage::fake or a temp output dir.
v2.0.0 has no usable changelog. The release body is a single auto-generated PR link. A major bump means something broke, but the notes won't tell you what. Before upgrading: read the full diff at github.com/dryven/faviconator/compare/v1.3.1...v2.0.0, and specifically check for (a) renamed/removed config keys, (b) renamed artisan command signature and options, (c) renamed Blade component or view namespace, (d) a major bump in intervention/image or a raised PHP/Laravel floor. Budget an upgrade task, not a composer update.
Republish config and views after the major. Published config files and overridden views are your copies — Laravel will not update them. A new major almost certainly expects new keys or a changed view structure, and a stale published config is the #1 cause of "the upgrade did nothing" or "undefined array key" errors. Diff your published copies against the package's originals. Same for view overrides: if the package's view markup changed, your override silently keeps rendering the old shape.
Browser favicon caching is aggressive and sticky. After regenerating, users (and you) will see the old icon for hours or days. Either version the filenames or append a cache-busting query string in the view override. When debugging "my new icon isn't showing," check in a private window and hit the icon URL directly before blaming the package.
Filesystem permissions and the public path. Generation writes into public/ — in containerized or read-only-filesystem deploys this fails, and it often fails quietly in the middle of a deploy. Run generation in a build stage, or point output at a writable disk and copy artifacts into place.
Missing GD/Imagick extension. Image manipulation needs a PHP image extension; the failure surfaces as a confusing exception from deep in the image library, not from the package. Confirm gd or imagick is enabled in the same PHP binary that runs artisan — a mismatch between CLI and FPM is a classic.
Clear caches after publishing. php artisan view:clear and php artisan config:clear after changing config or publishing views. With config:cache enabled in production, config edits that aren't followed by config:cache do nothing at all.
Extension points, in order of preference: (1) config values, (2) published view override, (3) a thin wrapper command of your own that sets config then calls the package command. Avoid subclassing internals — a major version is exactly when private/protected surfaces move, and v2.0.0's notes give you no warning.
Pin the version. Given the opaque release, constrain to ^2.0 only after you've reviewed the diff, and read the release body of every subsequent 2.x before bumping. If the changelog stays empty across releases, treat upgrades as code review tasks rather than routine maintenance.
How can I help you explore Laravel packages today?