Weave Code
Feature Flags Laravel Package
ylsideas/feature-flags
Extensible feature flags for Laravel to safely toggle code and features. Manage flags in application logic, routes, Blade views, scheduler tasks, and validation rules to support continuous integration and controlled rollouts.
A Laravel package for handling feature flags
Frequently asked questions about Feature Flags
- How do I enable feature flags for Laravel routes without manual middleware checks?
- Use the built-in middleware `FeatureFlagsMiddleware` to gate routes. Define flags in your `config/feature-flags.php` and apply the middleware to routes like this: `Route::middleware(['feature-flags'])->group(function () { ... })`. The package handles flag resolution automatically.
- Can I use feature flags to conditionally render Blade views?
- Yes. Use the `@feature` Blade directive to wrap sections of your views. For example: `@feature('new_ui') { ... }`. The directive checks the flag state and renders content only if the flag is enabled. Works seamlessly with Laravel’s Blade engine.
- What Laravel versions does ylsideas/feature-flags support?
- The package officially supports Laravel 10–13 (v3.x) and Laravel 9–11 (v2.x). Check the [README](https://github.com/ylsideas/feature-flags) for version-specific installation instructions. Avoid mixing v2 and v3 in the same project due to breaking changes in the pipeline system.
- How do I store feature flags in a database instead of memory?
- Configure the `database` driver in your `config/feature-flags.php` file. The package provides a migration to create the `feature_flags` table. Example: `'driver' => 'database'`. Flags will persist across requests and can be managed via Eloquent models or custom logic.
- Is there a way to test feature-gated logic in Laravel tests?
- Yes. Use the `fake()` method to simulate flag states in tests. For example: `Features::fake(['new_feature' => true])`. This overrides real flag values during testing, making it easy to verify feature-gated routes, Blade views, or validation rules.
- Does ylsideas/feature-flags work with Laravel’s query builder or Eloquent?
- Absolutely. The package includes Eloquent mixins to gate queries dynamically. For example: `Model::whereFeatureEnabled('premium_features')->get()`. This integrates with Laravel’s query builder and supports complex conditions like `whereFeatureDisabled()`.
- What are the performance implications of using feature flags?
- Performance depends on your driver. The `in_memory` driver is fastest but not persistent. For production, use `database` or `cache` drivers. Cache flags aggressively to minimize database calls. The package is optimized to avoid blocking requests during flag resolution.
- Is there a built-in admin dashboard to manage feature flags?
- No, but the package integrates with third-party tools like Laravel Nova or custom admin panels. Flagfox (a dedicated dashboard) is in development—join the [waitlist](https://www.flagfox.dev/#waitlist) for updates. You can also build a custom UI using the package’s API.
- How do I migrate from hardcoded feature checks (e.g., `if (config('flags.new_feature'))`)?
- Replace hardcoded checks with `Features::accessible('flag-name')`. For example: `if (Features::accessible('new_feature')) { ... }`. Use the `vendor:publish` command to generate a config file and start with the `in_memory` driver for testing before switching to `database` or `cache`.
- Can I use feature flags for A/B testing or gradual rollouts?
- Yes. Combine flags with Laravel’s request context (e.g., user segments, IP ranges) to target specific groups. For example: `Features::accessible('new_ui', request()->ip() === '192.168.1.1')`. Test rollouts by monitoring flag usage via debug logs or custom metrics.
Weaver
How can I help you explore Laravel packages today?