Weave Code
Symfony Ignition Bundle Laravel Package
spatie/symfony-ignition-bundle
Spatie Symfony Ignition Bundle replaces Symfony’s default exception pages with Ignition’s beautiful, customizable error pages, including dark mode. Install via Composer as a dev dependency and enable the bundle in config/bundles.php.
spatie/symfony-ignition-bundle replaces Symfony's default exception pages with Ignition, a beautiful and customizable error page for PHP applications. Install it as a dev dependency, enable the bundle in config/bundles.php, and your debugging experience instantly improves.
Configure it via config/packages/ignition.yaml to control the application path, dark mode, exception visibility, and whether HTML errors render for non-HTML requests.
- Gorgeous error pages with light and dark modes
- Drop-in replacement for Symfony's exception handler
- Dev-only bundle, so no production impact
- YAML configuration with sensible defaults
- AI-generated solution suggestions for exceptions
Frequently asked questions about Symfony Ignition Bundle
- Is spatie/symfony-ignition-bundle a Laravel package?
- No. It is a Symfony bundle that replaces Symfony's default exception renderer with Spatie's Ignition error page. Laravel applications already ship spatie/laravel-ignition, which is the correct package there, so adding this bundle to a Laravel app would just be dead weight. Use it only when the target application is built on Symfony.
- How do I install spatie/symfony-ignition-bundle in a Symfony app?
- Install it as a dev dependency with composer require --dev spatie/symfony-ignition-bundle. Then register the bundle in config/bundles.php as Spatie\SymfonyIgnitionBundle\IgnitionBundle::class => ['dev' => true]. A Symfony Flex recipe exists, so most of the setup is automated. No production container wiring or services need to change.
- Which PHP and Symfony versions does this bundle support?
- Current releases support PHP 8.2 and 8.3 with Symfony 7 and 8; Symfony 8 support landed in 1.3.0 and was corrected in 1.3.1. PHP 8.0 and Symfony 6.0/6.2 were dropped in 1.1.0. If any service still runs those older lines, it needs upgrading before you can adopt the bundle.
- What configuration options does ignition.yaml expose?
- Configuration lives in config/packages/ignition.yaml, usually inside a when@dev block. The main keys are application_path (typically '%kernel.project_dir%'), dark_mode, should_display_exception and force_html_response. You can inspect the full tree with bin/console debug:config ignition.
- Does Ignition support dark mode?
- Yes. Set dark_mode: true in your ignition.yaml config and Ignition renders its dark theme for error pages. It is purely a visual preference that only affects how exception pages look in the browser during development.
- What happens if Ignition is accidentally enabled in production?
- Ignition exposes source excerpts, environment context and stack arguments, so a bundle left enabled in prod is an information-disclosure incident. Keep it registered only for the dev environment and leave should_display_exception set to '%kernel.debug%'. A CI or config-lint check asserting the bundle is absent from config/bundles.php in production is a cheap guardrail worth adding.
- What does force_html_response do for JSON API routes?
- force_html_response, added in 1.3.0, makes Ignition render HTML error pages even for non-HTML requests such as JSON API endpoints. It defaults to false, which is the right setting for mixed web and API backends. Enable it only when developers want the full Ignition page for every request type while debugging locally.
- Is the openai_key option safe to use for AI error suggestions?
- The openai_key option, added in 1.2.0, turns on AI-generated solution suggestions for exceptions. It puts an API credential in YAML for a tool whose job is displaying app internals, and it sends stack traces to a third party on every error. For regulated or customer-data workloads that is a governance decision rather than a config toggle, and many teams disable it org-wide.
- How does Ignition compare to Symfony's native debug exception page?
- The real differentiators are solution providers, Flare reporting and AI-generated fix suggestions, not just a prettier error screen; Symfony's native debug page has improved substantially since 6.4. If all you want is a readable stack trace, the built-in page may already be enough. Ignition is best treated as a developer-experience tool alongside the profiler and VarDumper.
- Is spatie/symfony-ignition-bundle actively maintained enough to rely on?
- Adoption is thin, at roughly 29 stars and no dependents, and it is a thin convenience wrapper around the far more popular spatie/ignition library from a single vendor. For a dev-only dependency the blast radius of abandonment is small, since you simply fall back to Symfony's native debug page. Avoid building anything production-critical on top of it.
Weaver
How can I help you explore Laravel packages today?