- Do I need this Collision adapter in a Laravel application?
- No. Laravel already ships Collision transitively through laravel/framework, and Laravel's error rendering already includes the framework metadata line this adapter provides. Only consider it for standalone Symfony Console CLIs outside Laravel.
- What does nunomaduro/collision-adapter-symfony actually do?
- It is thin glue that tells Collision the Symfony framework name and version so Collision can print the correct framework metadata line alongside its exception rendering. Collision does the rendering, and Symfony Console still dispatches the error. It does not change the DI container, HTTP kernel, or business logic.
- How do I install the Collision adapter for Symfony Console?
- Require Collision and the adapter as dev dependencies with Composer, for example composer require --dev nunomaduro/collision-adapter-symfony. Then register Collision with the Symfony adapter in your CLI bootstrap before the kernel boots and before Application::run(). There is no configuration schema to publish.
- Which Symfony Console and Collision versions are supported?
- The adapter is intended for PHP 8.x with Symfony Console 6 or 7 and Collision 7 or 8. The adapter contract has changed across Collision majors, so verify compatibility when either Collision or Symfony Console is upgraded. Pin versions and test the CLI error path after major bumps.
- Where should I register the handler in bin/console?
- Register it in the CLI bootstrap behind an APP_DEBUG guard, before the kernel boots and before Application::run(). Ensure Collision runs last so it is not overridden by Symfony's ErrorHandler. Do not add it to public/index.php, which should keep symfony/error-handler.
- Will this give Symfony apps the same error output as Laravel?
- It gives Symfony Console apps Collision's rendering: syntax-highlighted exceptions, clear file references, and helpful context. It does not add Laravel-specific features or a Laravel-style debug page. Set expectations that the visible change is mainly the framework metadata line plus Collision's existing console formatting.
- Can I use this adapter with Symfony's ErrorHandler in production?
- Keep symfony/error-handler for production and HTTP entrypoints, and scope Collision to debug-mode console runs. Mixing Collision and Symfony's ErrorHandler can cause double rendering or prevent Collision from firing. The adapter only runs on the failure path, but handler order matters.
- Is this package safe for production CLI tools?
- It is MIT-licensed, installs via Composer, and has no native extensions, daemon, or runtime footprint beyond the failure path. The main risks are ownership and version coupling: it has a single maintainer, low adoption, and no documented security disclosure process. Install it as a dev dependency and verify behavior after upgrades.
- What are alternatives to collision-adapter-symfony?
- For Symfony Console apps, you can use Collision with this adapter, keep Symfony's default console exception renderer, or vendor the small adapter in-house if dependency governance requires it. For Laravel apps, use the Collision that already ships with laravel/framework and do not add this package. The adapter is small enough that in-house ownership is realistic, but confirm the exact surface first.
- Is collision-adapter-symfony actively maintained?
- It is first-party to the Collision author, which helps provenance, but it has low adoption, around 44 stars and no listed dependents, and a single maintainer. There is no SLA and no documented security process, so treat upgrades of Collision or Symfony Console as events that need verification. If you adopt it, assign an owner for compatibility checks.