- Can I use nusje2000/feature-toggle-bundle in a Laravel application?
- Not as a drop-in package. It is a Symfony bundle that ships a Bundle class, a DI extension, and a Symfony-native configuration tree, so it expects Symfony's Kernel and parameter bag rather than Laravel's container and config repository. The toggle resolution logic is conceptually framework agnostic, but in Laravel you would be writing an adapter layer yourself. Treat it as a library-plus-bridge, not a native Laravel install.
- How do I install and configure feature-toggle-bundle in Laravel?
- You can install it with Composer, but you cannot rely on Symfony auto-wiring or a bundle config tree. The practical approach is to register the toggle resolver as a container-managed singleton and hand-write a translation from config/features.php into whatever array or DTO the resolver consumes. Expose a narrow internal interface such as FeatureToggle::isActive(string $flag, array $context): bool and let the rest of your application depend only on that seam. Budget days rather than hours for a working integration.
- Does this package provide Laravel facades, config publishing, or Artisan commands?
- No. Those ergonomics are not part of the bundle, which is built around Symfony's DI extension and configuration tree. There is no config/feature-toggle.php, no publishable service provider, and no Artisan commands for listing or flipping flags. If you want those conveniences you will build and maintain them in your own bridge layer.
- What are the PHP and Symfony version requirements for version 6?
- The removal of myclabs/php-enum in favour of native PHP enums implies a PHP 8.1 floor, since native enums landed in 8.1. You should still read the require block in composer.json directly to confirm the exact minimum PHP and Symfony constraints before committing. The v6 changelog itself is minimal, so composer.json is the authoritative source.
- What breaking changes does feature-toggle-bundle v6.0.0 introduce?
- Two documented breaking changes: removal of the myclabs/php-enum dependency and added type declarations across classes. The enum removal is the higher-risk item, because any code that typed against, extended, or serialised MyCLabs\Enum\Enum instances for toggle names or strategies will break, and enum value access moves from getValue() to ->value. The added return and parameter types are a hazard for anyone who subclasses or decorates the bundle's classes, since an incompatible override becomes a fatal error rather than a warning.
- Is there an upgrade guide or migration notes for v5 to v6?
- No UPGRADE file or migration guide accompanies the release. The changelog is effectively two lines, so expect to diff v5.2.0 against v6.0.0 yourself. Plan for that diff to be part of your upgrade task, especially if you persist enum-backed toggle keys or expose them over an API, where stored values and JSON shapes may shift.
- Can I use the feature toggle resolver standalone, without booting Symfony?
- That is the key open question and it is not documented as a supported path. If the resolution core is cleanly separable from the Bundle bootstrapping and the configuration tree, you can instantiate it directly or inside a Laravel singleton. If it is not, your better option is to evaluate the underlying toggle library or a Laravel-native alternative rather than forcing the bundle into a non-Symfony host.
- How do I test feature toggles in a Laravel test suite with this package?
- Testing works best if you depend on your own FeatureToggle interface rather than concrete bundle classes, so tests can swap in a fake, in-memory implementation. Behind that seam you can assert flags are on or off per test and avoid touching real configuration. Be aware that the new type declarations in v6 can make existing test doubles written against v5 signatures fail fatally on incompatible overrides.
- Is this bundle production ready and well maintained?
- Adoption risk sits mostly with maintenance signal rather than code quality. There is a single primary contributor across the v6 pull requests, a major release shipped with a two-line changelog and no migration guide, and no documented security disclosure process. That does not make it unusable, but it means you own the upgrade work and should pin versions and read diffs rather than rely on release notes.
- What are the alternatives to this bundle for feature flags in Laravel?
- If you want native ergonomics, look at Laravel-first flag packages or a hosted flag service that ships a PHP SDK you can wrap in a service provider. If you only need simple runtime switches, a config-driven resolver of your own behind a FeatureToggle interface is often less work than adapting a Symfony bundle. Whichever you choose, keeping application code behind your own interface makes the next swap cheap.