Ignition Laracasts Tab Laravel Package

Getting Started

Install as a dev dependency so it never ships to production:

composer require --dev stefanbauer/ignition-laracasts-tab

The package uses Laravel package auto-discovery; there is no service provider to register manually in a stock Laravel 6/7 app. Once installed:

1. Confirm APP_DEBUG=true and APP_ENV=local (Ignition only renders in debug mode).
2. Trigger any exception — a broken route, throw new \Exception('test'), or an artisan dd()-adjacent failure.
3. Open the Ignition error page in the browser and look for the Laracasts tab alongside the default Solution, Stack Trace, and Context tabs.
4. Click the tab; it surfaces a Laracasts search seeded from the exception message so you can jump straight to screencasts/discussions.

Where to look first if something is off:

• vendor/stefanbauer/ignition-laracasts-tab/src/ — the tab class (a Spatie\Ignition\Contracts\Tab implementation) and the service provider that registers it.
• README.md in the vendor folder for the supported Ignition major version.
• composer show stefanbauer/ignition-laracasts-tab to verify the resolved version against your Ignition version.

First sensible use case: you’re debugging a cryptic framework exception locally, you’ve already read the stack trace, and you want to see whether Laracasts has covered the same error message. The tab gives you a one-click search without copy/pasting the message into a browser.

Implementation Patterns

Zero-config daily driver. The intended workflow is "install once, forget it." You don’t wire anything into your app — on each debug error page the tab is present and pre-populated with the exception message. Treat it like a bookmarked search engine attached to Ignition.

Pair it with the default tabs. Ignition’s strength is that tabs are additive. Use Solution for automated fixes, Stack Trace for the line of code, and the Laracasts tab when the exception is a "why does Laravel do this?" question rather than a "which line broke?" question. In practice the Laracasts tab is most useful for framework-level QueryException, MassAssignmentException, MethodNotAllowedHttpException, and validation-related messages.

Team onboarding. Since it’s a require-dev dependency committed in composer.json, every developer gets it after composer install. That makes it a cheap shared debugging affordance — no wiki page, no browser bookmark drift. Document it once in your CONTRIBUTING.md alongside barryvdh/laravel-debugbar and laravel/telescope.

Triggering it deliberately while learning. When you’re exploring a package or framework internals, throwing a temporary exception in routes/web.php (or a tinker session) to land on Ignition and search Laracasts for the message is a fast loop. php artisan tinker → throw new Exception('...') isn’t enough because Ignition renders via HTTP, so use a scratch route or abort(500, 'message').

Composing with other custom Ignition tabs. If you already register your own tabs (e.g. a "Docs" or "Internal Runbook" tab) via Ignition’s registerTab, the Laracasts tab sits alongside them without conflict. Keep each tab single-purpose and let Ignition handle ordering.

Local-only by design. If your team runs Docker/Valet/Herd, the tab works identically because it’s entirely server-rendered into the Ignition HTML — there’s no browser extension, no local daemon.

Gotchas and Tips

• It will not appear in production. APP_DEBUG=false disables Ignition entirely, so the tab disappears with it. That’s correct behavior, not a bug — don’t try to "fix" it.
• Ignition version coupling. This package targets the Ignition 1.x/2.x tab contract. If you upgrade to a Laravel version that ships a newer Ignition (or you install spatie/ignition standalone at a different major), the tab registration may silently stop working. Check the package’s composer.json constraint and the last release date (2020) against your Laravel/Ignition version before assuming it’s broken config.
• If the tab is missing, check discovery first:

  php artisan package:discover
  composer dump-autoload
  php artisan config:clear
  

  A stale bootstrap/cache/packages.php or config cache is the usual culprit in older apps that don’t re-discover on composer install.
• Exception messages are noisy. Framework messages often include fully-qualified class names, quoted values, and SQL fragments. The resulting Laracasts query can be too specific to return useful hits. When the tab’s search looks empty, copy a shorter distinctive fragment (e.g. MassAssignmentException) into Laracasts manually.
• Don’t leak sensitive data. Because the tab is seeded from the exception message, messages that embed credentials, tokens, or user input will be reflected into a URL. This is local-only, but be mindful when screen-sharing or recording demos — Ignition already flattens context, and a search URL containing a secret is easy to paste into a ticket by accident.
• Network/egress assumptions. Depending on version, the tab either builds a search URL you click or performs a lookup. In locked-down corporate networks, outbound access to laracasts.com may be blocked — the tab will still render, but results/links won’t resolve. Don’t chase this as a package bug.
• Extension point is the source, not config. There’s effectively no runtime configuration surface. If you want different search terms (exception class instead of message, app-specific keyword suffixes), fork the tab class or write your own Tab implementation and register it — copying this package’s ~50 lines is faster than patching it.
• Keep it out of CI artifacts. As a dev dependency it won’t ship, but if you build a Docker image with --no-dev locally and then try to reproduce a production error, the tab won’t be there. That’s expected; reproduce in a dev container instead.
• Low-maintenance shelf life. With a 2020 last release and ~53 stars, treat it as a small, stable utility rather than an actively maintained package. If it ever breaks against a new Ignition major, the fallback is trivial: delete it and search Laracasts manually — nothing in your application code depends on it.