- Is steevanb/dev-bundle compatible with Laravel?
- It is a Symfony bundle, not a Laravel package. It registers through Symfony's kernel and relies on HttpKernel, DependencyInjection and the Profiler, none of which have an equivalent in a Laravel application. Laravel has no bundle registration, no Symfony Profiler and no Symfony container semantics to inspect, so the package cannot be dropped in as-is. Laravel teams should use first-party tooling instead of shimming a Symfony bundle into Laravel's container.
- How do I install steevanb/dev-bundle?
- Install it with Composer as a dev dependency using an explicitly pinned version rather than a floating constraint. Then register it in config/bundles.php gated to the dev and test environments only. Pinning matters because Symfony dev bundles with tight constraints tend to become the obstacle during the next framework major bump.
- What does steevanb/dev-bundle actually do?
- Per its description it is a developer-ergonomics bundle for Symfony: profiler panels for services, routes and Twig, console commands for container inspection, and Twig helpers. Some third-party assessments instead describe a translation-key guard and a Doctrine schema validator, which are different capabilities entirely. Treat that contradiction as a documentation provenance problem and verify the real behaviour in the repository before adopting.
- Will steevanb/dev-bundle affect my production environment?
- It is designed to stay out of the way outside the dev environment, but only if you register it conditionally. Registering it unconditionally can surface inspection panels and debug helpers in production, which is at minimum a performance cost and at worst an information disclosure risk. Gate it in config/bundles.php to dev and test only.
- Which Symfony and PHP versions does steevanb/dev-bundle support?
- The available context does not state a support matrix, so check the repository's composer.json against your Symfony and PHP versions before adopting. With a single-maintainer, zero-star package there is no community validation to confirm compatibility. Pin the exact version you tested and re-verify on every Symfony major upgrade.
- Does steevanb/dev-bundle replace the Symfony Profiler?
- No, and it overlaps substantially with it. Symfony's built-in Profiler already covers a large part of what is advertised, so benchmark the delta before adding the dependency. If the extra value is thin, drop the package.
- What should Laravel developers use instead of steevanb/dev-bundle?
- Use laravel/telescope for request, job and query visibility, plus artisan about, config:show, route:list and event:list for introspection. For template inspection, view:cache and Blade linting cover the equivalent need. These first-party tools deliver the same capability with zero supply-chain exposure.
- How do I prove the bundle is not loaded in production?
- Add a CI step that builds the production container and asserts the bundle is absent from the registered bundle list. This is the single most important guardrail for any dev-only Symfony bundle. Combined with a pinned require-dev constraint, it keeps the blast radius contained.
- Is steevanb/dev-bundle actively maintained?
- There is no strong signal: zero stars, zero dependents, a single maintainer and no community validation. That does not make the code bad, but it does mean you own the upgrade path. Have a plan for when it stops tracking Symfony majors.
- Is steevanb/dev-bundle safe to add to an existing Symfony service?
- For a Symfony dev and test environment already using the Profiler it is low risk: install as require-dev, pin the version, and register it only in dev and test. Budget roughly half a day for setup and for benchmarking the delta against the stock Profiler. Do not attempt it on Laravel, where the impedance is the framework lifecycle rather than the autoloader.