Weave Code
Feature Flags Laravel Package
ylsideas/feature-flags
An extendable Laravel package for managing feature flags in code, routes, Blade views, task scheduling, and validations—making continuous integration and deployment easier by safely guarding features behind toggles.
ylsideas/feature-flags is an extendable and adaptable Laravel feature flag package for safely integrating and deploying features. Define flags in code and guard application sections so functionality only runs when a flag is switched on.
- Supports code, routes, Blade views, scheduled tasks, and validations
- Simple flag checks across Laravel applications
- Extendable architecture for custom flag behavior
- Reduces deployment risk with controlled feature rollout
Frequently asked questions about Feature Flags
- How do I install ylsideas/feature-flags in a Laravel application?
- Install it with Composer using composer require ylsideas/feature-flags, then publish the package config with php artisan vendor:publish so a features.php file is added to your config directory. The service provider and Features facade are auto-discovered, so no manual registration is required on supported Laravel versions. After publishing, define your flags and start checking them through the Features facade.
- Which Laravel and PHP versions does this feature flags package support?
- Version 3 targets Laravel 12 and 13 with PHP 8.4 tooling, while earlier releases cover Laravel 9 through 11, and Laravel 13 support arrived in v3.1.0. Support for new Laravel majors has historically landed quickly, with Laravel 11 in v2.5.0 and Laravel 12 in v3.0.0. Because the package is Laravel-only, pin a major version and check the changelog before upgrading across major releases.
- How do I define and check a feature flag with ylsideas/feature-flags?
- Flags are defined in code, typically in the published features.php config when using the in-memory or config driver, and you check them through the Features facade, for example Features::accessible('my-flag'). The same call sites keep working if you later move flag state into a database or cache driver. This lets you start with a small proof of concept and change the backing store without rewriting application code.
- What drivers does the package provide to store feature flag state?
- Since v2 the package uses a pipeline and gateway abstraction with composable drivers: in-memory/config, database, cache, gate, and chain. You choose which driver holds authoritative flag state and can swap drivers without touching call sites. Teams should explicitly document the fallback behaviour when the chosen store is unavailable and the expected propagation latency for toggles.
- How do I use feature flags in routes and Blade views?
- The package ships first-class Laravel integration points, including route middleware for guarding endpoints and Blade directives for wrapping template sections. That means you can gate whole routes or fragments of markup without hand-writing conditionals around every check. If you need per-user or per-tenant targeting, evaluate whether the gate driver covers it or whether a custom gateway is required.
- How do I fake feature flags in Laravel tests?
- Use Features::fake() to swap real flag resolution for deterministic values during tests, and since v2.6.0 you can register multiple simultaneous fakes. This keeps CI fast and avoids depending on a database or cache store being present during the test run. It is one of the lower-effort parts of adopting the package.
- Can I query Eloquent models based on feature flag state?
- Yes. The package provides an Eloquent query-builder mixin with whenFeatureIsAccessible() and whenFeatureIsNotAccessible(), so you can conditionally constrain queries based on flag state. That is useful for gradual rollouts where only some records or tenants should see new behaviour. It is one of the broader Laravel integration points that distinguishes this package from plain config flags.
- How do I put scheduled tasks and validation rules behind a feature flag?
- Task scheduling and validation rules are both first-class integration points, so you can register a scheduled job or a validation rule only when the relevant flag is on. This supports incremental rollout of background work and input rules without leaving dead code in production paths. Keep a lifecycle policy per flag so these guarded paths get cleaned up when the rollout finishes.
- Is ylsideas/feature-flags actively maintained, and does it include a dashboard or audit trail?
- The package is effectively single-maintainer with occasional contributors, but release cadence is healthy and new Laravel versions are supported quickly, which mitigates the bus factor. It does not include a UI, audit trail, approvals, or role separation for toggling flags; Flagfox, the companion dashboard, is a separate waitlist-stage product. If you need change control over flag state, plan to build or buy that separately.
- How does caching affect feature flag correctness, and how do I inspect flag state?
- The cache driver stores resolved flag state, and v3.0.1 added a fix that forces boolean casting of cached results, so cache TTL and invalidation must be an explicit design decision. For kill-switch scenarios, measure the propagation latency from toggle to effect and confirm it meets your incident response needs. The feature:state console command and the debugging hook for flag access help you verify what the application currently sees.
Weaver
How can I help you explore Laravel packages today?