- Can I use spiechu/symfony-commons-bundle in a Laravel application?
- Only conditionally. The package is a Symfony bundle, so Laravel will not boot its service configuration or profiler data collector; realistically you can reuse only the framework-agnostic PHP classes and value objects, and only if those files have no hard Symfony runtime dependencies. Full bundle usage would require a Symfony kernel or a custom bridge, which is rarely worth maintaining inside a Laravel app. Run a short spike on a non-production branch before committing to the dependency.
- How do I install spiechu/symfony-commons-bundle with Composer?
- Install it with composer require spiechu/symfony-commons-bundle, pinning the exact tag or 0.3.* since the package is pre-1.0. Composer installation itself is straightforward, but Laravel will not auto-discover the bundle or register its services. Check composer.json for PHP, Symfony, and optional Twig constraints before installing to avoid conflicts with Illuminate packages.
- Does Laravel automatically register the Symfony bundle and its services?
- No. Laravel only auto-discovers its own service providers, so a Symfony bundle's DI extension and service configuration will not be loaded automatically. You would need a Symfony container context or a hand-written bridge to use the bundle's shared services. For most Laravel projects, consuming individual classes is the more sensible path.
- Which classes in the package are framework-agnostic and safe to reuse outside Symfony?
- The package describes itself as a collection of reusable common utilities, helpers, and base classes, and those standalone PHP classes are the most likely candidates for reuse. You must verify each class does not trigger bundle service loading or depend on Symfony runtime components, since the bundle also ships DI and profiler integration. Inspect the autoload rules and service configuration before relying on any class.
- Which PHP and Symfony versions does spiechu/symfony-commons-bundle support?
- The package targets Symfony, so its constraints are expressed in terms of PHP and Symfony package versions rather than Laravel versions. The technical evaluation specifically flags that PHP, Symfony, and optional Twig constraints must be checked against your dependency graph. Read composer.json and confirm compatibility with your Laravel and Illuminate versions, because a hard Symfony framework requirement at an incompatible version can block installation entirely.
- Do I need Twig to use the data collector?
- No. Version 0.3 fixed the data collector so it works without Twig, which helps non-Twig stacks. That said, the data collector is a Symfony profiler concern and has little practical value in a Laravel application. Twig remains optional for the bundle as a whole.
- Are value object invariants enforced only through assert()?
- The 0.3 release added assert() usage for value objects, which is a risk if those assertions are the only enforcement of domain invariants. PHP assertions can be disabled in production with zend.assertions=-1, so behavior should not silently change when they are off. Verify that explicit exceptions or validation paths exist, and test the value objects with assertions both enabled and disabled.
- Is version 0.3 stable enough for production, and what is the backward-compatibility policy?
- Treat 0.3 as pre-1.0: there is no documented backward-compatibility guarantee for 0.x releases, so pin the exact version. The release appears mostly corrective and quality-focused compared with 0.2.1, adding functional tests and PHPStan level 4, but that is not a stability promise. Run your full test suite after any upgrade and review the changelog.
- Do the functional tests cover the non-Twig data collector path and value object behavior?
- The evaluation notes that functional tests were added, which is a positive quality signal, but it does not confirm coverage of the non-Twig data collector path or all value-object behavior. Review the test suite in the repository to see what is actually exercised. If you depend on a specific class, add your own tests for it in your application.
- What alternatives should Laravel developers consider instead of this bundle?
- For a Laravel-first stack, consider framework-agnostic utility libraries or simply writing the small helpers and value objects you need directly in your app. Laravel's own support components and standard PHP value objects often cover the same ground without pulling in a Symfony bundle. If one specific class in this package is valuable, extracting or forking it usually costs less than maintaining a bridge.