Laravel Appleseed Laravel Package

Getting Started

Resolve what you are installing before you write a line of code. The package metadata is contradictory: the registry description and description.md advertise a Faker-backed Eloquent seeder generator, while the repository name, the prior assessments, and the only release note (0.2.1: "pattern matching... caused it to match on base route /") all describe a route shim that returns a clean 404 for missing favicon / apple-touch-icon requests so they stop landing in the exception handler as NotFoundHttpException. These are two different packages. Before adopting, open the actual tagged source at v0.2.1 and confirm which artifact you have. Everything below assumes the favicon-suppression behavior, because that is what the release history and the route-pattern fix describe.

Where to look first in the source. One service provider, one route registration. Find:

1. The service provider class and whether it registers unconditionally in boot() or behind a config flag.
2. The route pattern(s) it matches — the 0.2.1 fix is specifically about a pattern that over-matched, including /.
3. Whether it publishes anything into public/ (and whether that path is gitignored in your project).
4. Whether there is an extra.laravel block. There won't be — auto-discovery didn't exist in 2015, so manual provider registration in config/app.php is required on any 5.x project.

Try the resolution before you try the install. On anything modern, run composer why-not laravel/framework against the package, or just attempt composer require genealabs/laravel-appleseed in a scratch branch. The illuminate/* constraint almost certainly pins to the 5.0/5.1 window; if it doesn't resolve, stop here and go to the reimplementation path.

First use case — and the one that actually ships. The realistic day-to-day use on a maintained codebase is not the package, it is the pattern. The minimal native equivalent is three routes:

// routes/web.php
Route::get('/favicon.ico', fn () => abort(404));
Route::get('/apple-touch-icon.png', fn () => abort(404));
Route::get('/apple-touch-icon-precomposed.png', fn () => abort(404));

…or, better, three lines at the edge so PHP is never booted:

location = /favicon.ico                      { return 404; }
location = /apple-touch-icon.png             { return 404; }
location = /apple-touch-icon-precomposed.png { return 404; }

But check the strictly-better option first. A ~1KB real .ico in public/ plus a <link rel="icon"> tag eliminates the request class entirely. That is the default recommendation; the 404 handler is the backstop for bots and stray paths, not the primary fix. Only take the 404 route when you have deliberately decided not to ship icons.

Implementation Patterns

Pattern 1 — Native middleware (preferred over a route for maintainability). A route is fine for three static paths, but a small middleware keeps the behavior testable and lets you drive a configurable path whitelist:

class SuppressMissingAsset404s
{
    public function handle($request, Closure $next)
    {
        $paths = config('assets.missing_404s', [
            'favicon.ico',
            'apple-touch-icon.png',
            'apple-touch-icon-precomposed.png',
        ]);

        if (in_array($request->path(), $paths, true)) {
            return response()->noContent(404)
                ->header('Cache-Control', 'public, max-age=86400');
        }

        return $next($request);
    }
}

The Cache-Control header matters: without it, a crawler that respects caching will re-request every crawl, and you have moved the noise rather than removed it.

Pattern 2 — Edge rule as the primary, app middleware as the backstop. The best day-to-day ergonomics are: location = rules in nginx/Caddy for the three canonical paths, plus middleware for the long tail (apple-touch-icon-120x120.png, etc.). The edge rule removes both the log entry and the PHP boot cost; the middleware catches variants you didn't anticipate. This two-layer approach is the one worth writing down as a team convention.

Pattern 3 — Conditional registration behind a config flag. If you are on a legacy 5.x app where you must run the actual package (or your fork), verify the provider can be toggled — e.g. config('appleseed.enabled') — and default it off in testing. A route that silently intercepts /favicon.ico in every environment, including test, makes for confusing assertions when your test suite later adds its own favicon route.

Workflow — verify, then lock it in. After implementing, confirm with curl -I https://staging/favicon.ico that you get a 404 (not a 500, not a 200 from a stale asset) and check the response headers include your Cache-Control. Then write a one-line smoke test asserting no log entry is written on a GET /favicon.ico — that is the actual acceptance criterion, not "the route exists." Without it, the next framework upgrade can quietly stop the provider from booting and nobody notices until the logs are noisy again.

Integration tip — distinguish the two "fix" layers in code review. The route/middleware layer prevents the request from producing an exception. The logging layer (exception handler) decides what level a 404 gets logged at. If your handler logs every 404 at error, fixing that is higher leverage than routing around it, and it fixes every other missing-asset class at once. Do not let a per-path shim be mistaken for a logging-policy fix.

Do not confuse this with the seeding package. If someone expects php artisan appleseed:seed or Faker-generated rows, they are reading the wrong description.md. If the actual installed artifact is the seeder (verify by listing commands after install), then none of the above applies and you are evaluating a data-tooling package — treat it as a separate assessment, and note that a 2015 seeder generator is very unlikely to resolve against a modern illuminate/database.

Gotchas and Tips

The 0.2.1 bug is instructive — your implementation has the same failure mode. The release note exists because a route pattern matched / and possibly other routes, not just the icon paths. When you reimplement, match on exact paths ($request->path() === 'favicon.ico'), not on prefixes or regex, and never match the base route. Write a test that asserts / still resolves normally — that is the regression the upstream package shipped.

Route shadowing and boot order. If your app already registers something for /favicon.ico (a real asset route, a CMS catch-all, a service worker), the package's route may or may not win depending on provider boot order. On modern Laravel with bootstrap/app.php, provider ordering is different from 5.x's config/app.php array. Always confirm which route answers with php artisan route:list --path=favicon.

Abandonment is not cosmetic. Last release 2015-11-17, 30 stars, zero dependents, no CI, no test suite, no extra.laravel block. Concretely: auto-discovery will not work (register the provider manually), PHP 8.x will surface deprecation notices from 5.4-era idioms, and the illuminate/support constraint will likely block composer require on Laravel 8+. The maintainer is listed as mike-bronner while the vendor prefix is genealabs — another inconsistency worth noting, not just trivia.

The real root cause is often the exception handler. Sample one week of logs: count icon-related lines as a share of total error volume and of ingested bytes. If the number is under a few minutes of engineer attention per week, this is opportunistic debt hygiene, not a sprint. If the number is large, check whether your handler logs all 404s at error before you route around them — that fix is a two-line change and covers more ground.

Extension points are effectively yours to invent. The package as shipped offers no configurable path list, no Cache-Control on its 404, and no coverage of the sized apple-touch-icon-NNxNN.png variants. If those matter — and in production they do — you are writing them yourself anyway, which is the argument for owning the 30 lines rather than forking the 30 lines.

Watch the public/ interaction. If you later decide to ship a real favicon, and your route/middleware unconditionally 404s /favicon.ico, you will shadow the real file. Guard the handler with a file_exists(public_path(...)) check, or scope the rule to "no corresponding file on disk" in your web-server config — that is exactly the behavior the pattern is supposed to express, and the easy place to get it wrong.

Documentation integrity is a diligence finding. A package whose README describes a different product than its release notes is a package whose README you cannot write acceptance criteria against. If you adopt anything here, adopt the pattern and cite your own code, not the upstream doc.