- Does symfonyid/symfony-bundle-plugins support Laravel?
- No. Despite being distributed via Composer, this is a Symfony bundle and relies on Symfony's kernel and dependency injection container. Laravel has no bundle kernel, and there is no shim that makes a Symfony bundle usable inside Laravel's service container. It should not be triaged as a general Laravel/PHP dependency; scope it only to Symfony-based hosts.
- How do I install symfonyid/symfony-bundle-plugins?
- Install it with composer require symfonyid/symfony-bundle-plugins, then register the bundle in config/bundles.php. There is no Flex recipe, so every registration and configuration step must be done manually and validated by your team. Check the package's composer.json for exact Symfony and PHP constraints before committing.
- How does symfony-bundle-plugins discover and register plugins?
- The README excerpt does not specify the discovery mechanism, and the technical evaluation flags this as a key open question. Discovery could be DI tags, PHP attributes, config files, or a service locator, and the answer materially changes the integration effort. Run a sandbox spike to confirm the mechanism before adopting the bundle.
- Does symfony-bundle-plugins use compiler passes or a runtime registry?
- The package blurb states it uses dependency injection tags and compiler passes, which is the architecturally correct approach for Symfony. The evaluation warns that it only fits cleanly if plugin discovery integrates with Kernel::build and ContainerBuilder tags rather than inventing a parallel registry. Verify in source whether plugins resolve at container compilation time or at runtime.
- Which Symfony and PHP versions does symfony-bundle-plugins support?
- Supported Symfony and PHP version ranges are not visible in the package metadata, and there is no CI evidence surfaced in the assessment. Read composer.json constraints directly and test against your target Symfony major. Because there are zero dependents, no one has published real-world compatibility data.
- Is there a formal PluginInterface in symfony-bundle-plugins?
- The assessment lists a formal PluginInterface and documented lifecycle as an open question, not a confirmed feature. You should inspect the source for a published contract covering register, boot, and shutdown behavior. If no contract exists, define your own internal plugin convention before building on top of it.
- Is symfonyid/symfony-bundle-plugins safe for production?
- Treat it as high technical risk: zero stars, zero dependents, no battle-testing against real Symfony majors, and a likely bus factor of one. Plugin systems are a code-execution surface, so dynamically loaded plugins are a supply-chain and privilege-escalation vector if sourced from untrusted packages. The MIT license is a mitigation because fork-and-own is legally cheap, which is the right hedge for a 0-star dependency.
- How are plugin version conflicts handled in symfony-bundle-plugins?
- Conflict resolution between plugin-to-host and plugin-to-plugin versions is not documented and is flagged as an open question for the maintainer. You will likely need to codify an internal convention for naming, discovery, and version constraints. Test conflicting plugin combinations in a sandbox before relying on the bundle in a real distribution.
- What are the alternatives to symfony-bundle-plugins for Symfony extensibility?
- Symfony already provides bundle config trees, compiler passes, service tags, and event subscribers as first-class extension points. This package layers a nested model on top, letting bundles have plugins, which is useful when shipping third-party feature packs without forking a host bundle. Evaluate whether native DI extension points already meet your needs before adding a second, less-documented mechanism.
- Is symfony-bundle-plugins maintained and tested?
- Maintenance cadence, tagging discipline, and test coverage are unknown, with zero adoption and no public issue history to gauge responsiveness. The assessment recommends a sandbox spike that proves register, boot, override, and teardown across kernel, cache warmup, and CLI contexts. Given the MIT license, plan for the possibility of forking and owning the code.