Ignition Stackoverflow Laravel Package

Getting Started

astrotomic/ignition-stackoverflow is a dev-only Ignition solution provider: when an exception is thrown in a local/staging environment, the Ignition error page gains a "Search Stack Overflow" action that opens a pre-filled Stack Overflow search for the exception. It is not a runtime error handler — nothing changes for your users, and it should never reach production.

Minimal setup:

composer require --dev astrotomic/ignition-stackoverflow
php artisan vendor:publish --tag=stackoverflow-config   # inspect the tag/provider in the package README

• Package auto-discovery registers the solution provider with Ignition; no config/app.php edit is needed unless you have extra.laravel.dont-discover set.
• Publish the config and read it first — that file is the entire public surface of the package (search query construction). Everything else is Ignition's own config/ignition.php.
• First use case: throw something realistic in a local route (e.g. an Eloquent QueryException or a TypeError from a typo'd argument), open the error page, click the Stack Overflow action, and confirm the resulting query is something you'd actually have typed yourself. If it isn't, that's a config problem, not a package problem.

Version 1.7.0 is a low-risk release: explicit PHP 8.0 support and a search-query cleanup. Nothing to migrate.

Implementation Patterns

Treat the config as team infrastructure. The value of this package is entirely in the quality of the generated query. Commit the published config and tune it once so every developer gets the same useful search instead of a URL containing a stack trace, a UUID, and their home directory.

Sanitize before you search. Raw exception messages are full of noise: quoted SQL, integer IDs, absolute paths, timestamps, generated class names. A query that includes them returns zero results. In your config's query callback/template, normalise aggressively:

// config/stackoverflow.php (shape may vary by version — check the published file)
'query' => function (\Throwable $throwable): string {
    $message = $throwable->getMessage();

    // strip volatile fragments that poison a search
    $message = preg_replace('/\b[0-9a-f]{8}-[0-9a-f-]{27,}\b/i', '', $message); // UUIDs
    $message = preg_replace('/\b\d+\b/', '?', $message);                         // IDs, line numbers
    $message = preg_replace('/[\'"][^\'"]{40,}[\'"]/', '...', $message);         // long literals
    $message = str_replace([base_path(), storage_path(), PHP_EOL], ['', '', ' '], $message);

    return trim(preg_replace('/\s+/', ' ', $message)) . ' laravel';
},

Keep the class name and file basename, drop the message tail. SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry searches well; the same string with a 36-character UUID appended does not.

Coexist with Ignition's solution list. Ignition's config controls which solution providers run. If you want this provider only on some environments (say, local but not staging), gate it there rather than removing the package:

// config/ignition.php
'solutions' => [
    // ...
    Astrotomic\IgnitionStackOverflow\IgnitionStackOverflowServiceProvider::class,
],

Use it as a template for internal solutions. The package is small and its real lesson is the SolutionProvider contract: once you've seen it work, the same pattern gives you "Search our Confluence", "Open the runbook for this queue", or "This exception means X — see ADR-14". Copy the provider shape rather than writing a bespoke Ignition extension.

Deployment hygiene. Keep it in require-dev, deploy with composer install --no-dev, and confirm your base composer.json doesn't accidentally promote it to require (a common outcome of running composer require without --dev).

Gotchas and Tips

• 1.7.0 changes your search URL. base_path() was removed from the query construction. Two consequences: queries are now machine-independent (good — the same error produces the same link for everyone), and anyone who patched around the old behaviour, or who wrote a query callback assuming paths were already stripped, should re-verify what the generated URL looks like. Re-run a familiar exception and eyeball it once after upgrading.
• PHP 8.0 is supported explicitly as of 1.7.0, but "supports 8.0" is not "supports 8.3". Ignition's major line is tied to the Laravel version; on Laravel 9+/Ignition 2, check the installed spatie/ignition / facade/ignition constraint before assuming the provider still renders. If the action silently disappears, suspect an Ignition major bump, not a bug in this package.
• Solution missing from the error page? Work through these in order: is APP_DEBUG=true; is the package installed without --no-dev; did auto-discovery get disabled globally; does config/ignition.php's solutions array still list the provider; is config:cached from an older state. php artisan config:clear fixes a surprising share of "the package doesn't work" reports.
• Ignition 2's UI differs from Ignition 1's. Screenshots and click paths in blog posts won't match. Look for the solutions/runnable-solutions region on the error page, not a literal button labelled the same way.
• Stack Overflow search is a smell detector. If the same query keeps surfacing unrelated questions, that's usually a signal the exception message is generic and the useful information is in the previous frame. Search the wrapped exception's message instead of the wrapper's.
• No network calls are made by the package — it only builds a URL. That means it's safe in air-gapped setups, and it also means "it does nothing" is never a firewall issue; the link is wrong or the provider isn't loaded.
• Don't rely on it for production triage. With debug off, users see the generic error page and this provider contributes nothing. Pair it with real exception reporting (Sentry, Flare); treat this as a local ergonomics tool, not monitoring.