- Is jms/debugging-bundle a Laravel package?
- No. It is a Symfony2-era bundle built on Symfony\Component\HttpKernel\Bundle\Bundle, dependency-injection compiler passes, and Symfony Console commands, none of which exist as extension points in a Laravel application. Laravel has no bundle system, so there is no place for the bundle to register itself. Treat it as a pattern reference for developer-experience tooling, not as an installable dependency.
- What does jms/debugging-bundle actually do?
- It adds introspection tooling to Symfony applications: inspecting container services, tags, aliases and parameters, listing event listeners with dispatcher priorities, tracing service definitions and dependency wiring, and reading framework configuration from the console. Some versions also add a debug toolbar, request profiling, and detailed exception pages. The value is understanding how a container and event dispatcher are wired without writing ad-hoc debug code.
- Why does composer require jms/debugging-bundle fail in Laravel 10 or 11?
- The bundle targets Symfony 2.0 through 2.2, PHP 5.3 and 5.4, and PSR-0 autoloading. Requiring symfony/framework-bundle ~2.x collides with the Symfony components Laravel already pins, such as symfony/console ^6, symfony/http-foundation, and symfony/process. Composer resolution fails before any code runs, so there is no runtime workaround. Do not add it to require or even require-dev in a Laravel project.
- Can I install jms/debugging-bundle as a dev dependency in Laravel?
- No. require-dev changes nothing about Composer's dependency graph, so the Symfony 2.x constraints still conflict with Laravel's own packages. The bundle also relies on framework APIs that were removed in Symfony 3 and 4. Any vendored or forked copy would be net-new maintenance, not a dependency install.
- What are the Laravel equivalents of the bundle's container and service introspection?
- Use php artisan about for a framework and environment overview, and Tinker against app()->getBindings() or the container's bindings and instances for service graphs. Laravel Telescope covers request and event tracing, while php artisan route:list -v, php artisan config:show, and php artisan view:cache or view:clear handle route, config, and view debugging. For step-level inspection, Xdebug with an IDE remains the strongest tool. Only build custom tooling for gaps those tools genuinely leave open.
- Can I port JMSDebuggingBundle to Laravel instead of installing it?
- A port is effectively a rebuild, because the original source is a specification rather than a starting point. You would translate bundle services into a single service provider, compiler passes into afterResolving or extend hooks and a boot-time reflector, and Symfony commands into guarded Artisan commands. Replace Twig diagnostics with Blade error traces and equivalents. Budget it as net-new development owned by your team.
- Which PHP and Laravel versions does jms/debugging-bundle support?
- It targets PHP 5.3 and 5.4 with Symfony 2.0 to 2.2, which is roughly a decade behind current PHP 8.1+ and Laravel 10 or 11 targets. The upstream project is dormant, with 159 stars and zero dependents, so no compatibility work is expected. Verify the exact composer.json constraints before writing any code, but expect them to confirm the hard block.
- Is jms/debugging-bundle safe to run in production?
- No. A tool that dumps environment variables and container internals is a security surface, and any vendored copy would carry unpatched PHP 8 compatibility issues and deprecation warnings. Upstream is unmaintained, so no fixes are coming. If you build similar tooling yourself, gate it behind APP_DEBUG and app()->environment('local') or an explicit opt-in flag, and make one owner responsible for enforcing that gate.
- How does jms/debugging-bundle compare to Laravel Telescope or Debugbar?
- Telescope, Debugbar, Ray, and Xdebug are Laravel-native or framework-agnostic and cover request profiling, exception rendering, query and log panels, and step debugging. The JMS bundle offers comparable intent for Symfony 2 but cannot run in Laravel at all. Evaluate the Laravel tools first and only look for a residual gap if they demonstrably miss a capability you need.
- Should I fork jms/debugging-bundle to keep using its features?
- Only if a specific, confirmed capability gap remains after Telescope, Debugbar, Ray, and Xdebug have been ruled out on stated grounds. A fork means owning PHP 8+ compatibility, removed functions and deprecated syntax, plus the JMS namespace collision risk if jms/serializer is ever introduced. For most teams, reference-only is sufficient to close the question. Marking the evaluation as unmet-need signal, rather than adoption, is the correct outcome.