- Can I install lwiesel/feature-checker-bundle in a Laravel application?
- No. This is a Symfony2 bundle, not a Laravel package: it ships a bundle class, a DI extension with a configuration tree, and a container-managed FeatureChecker service, none of which Laravel's service container or package discovery understands. There is no service provider, no facade, and no supported boot path. For Laravel, use Laravel Pennant (10.31+) or write a small config-driven checker of your own.
- What Laravel version does lwiesel/feature-checker-bundle support?
- None. The package targets the Symfony 2.x kernel and PHP 5-era code, so its Composer constraints (php 5.x, symfony/symfony ~2.x) cannot coexist with Laravel 10, 11, or 12. Forcing it in with --ignore-platform-reqs only defers the failure to runtime, where removed container and kernel APIs will fatal. Treat any claim of Laravel compatibility as incorrect.
- Why does composer require lwiesel/feature-checker-bundle fail dependency resolution?
- The package's last release is from March 2015, so its requires pin PHP 5 and Symfony 2 components that no longer satisfy a modern application's dependency graph. Composer reports that your root requirements and the bundle's constraints cannot be resolved into a compatible set. Ignoring platform requirements installs files that will not autoload or boot correctly on PHP 8.
- Does this bundle work with PHP 8 or Symfony 5, 6, or 7?
- No. The code predates scalar type declarations, PHP 8 syntax changes, and the Symfony 3+ service-definition and container-compiler conventions. Modernizing it means rewriting the service wiring, adding types, and replacing deprecated constructs. At that point you have written a new package and inherited the old one's baggage, so a fresh implementation is usually cheaper.
- Is lwiesel/feature-checker-bundle still maintained and safe for production?
- There is no visible maintenance: the last release was 2015-03-03, roughly 13 stars, no dependents, and no security triage or issue activity. Feature flags are high blast-radius code because a wrong default can silently ship unfinished functionality or disable a working path. With no tests or documented default behavior for missing flags, we would not put this in a production release path.
- How do you configure and register this bundle in a Symfony 2 application?
- You require it with Composer, register the bundle in AppKernel, and define your flags under the bundle's key in config.yml, where the DI extension's configuration tree validates them. The container then exposes the FeatureChecker service for injection into your own services and controllers. Because the package is unmaintained, verify the exact config key and method names against the source rather than assuming the README is current.
- How do I check whether a feature is enabled in a controller or Twig template?
- The intended pattern is to inject the container-managed FeatureChecker service and call its boolean check with a feature name, and to expose the same check through a Twig helper for templates. The concept is a config-driven boolean lookup, so the API surface is small and easy to reproduce. If you are rebuilding this on Laravel, the equivalents are the Feature facade plus the @feature Blade directive.
- What is the Laravel alternative to this Symfony feature-toggle bundle?
- Laravel Pennant is the first-party answer: it provides a Feature facade, per-scope resolution, middleware, Blade directives, and an events hook, with active maintenance and support for current Laravel versions. If you need percentage rollouts, remote kill switches, or an audit trail, evaluate Unleash, GrowthBook, or LaunchDarkly SDKs instead. Pennant covers static, per-user, and simple rollout cases that this 2015 bundle never did.
- Can this bundle do per-user targeting, percentage rollouts, or kill switches?
- Almost certainly not. A 2015 config-only checker supports static on/off flags read from configuration, which means changing a flag requires a config deploy. Per-user, per-tenant, and percentage targeting need a dynamic flag source plus a stable bucketing strategy, and kill switches need a runtime data store and an ownership model. Budget one to three developer-days for the static version and one to two weeks if targeting and an admin surface are in scope.
- How do I migrate off lwiesel/feature-checker-bundle without rewriting my app?
- There is no code migration, only concept migration: read the bundle's README and source to extract the intended API surface, typically an isEnabled(string $feature): bool method, a features config block, and a template helper. Re-express that as a FeatureChecker interface, a config-driven provider, an optional database or cache provider for dynamic flags, and the matching controller and template helpers. Keep the interface identical so call sites do not change, then delete the dependency.