- What is juststeveking/laravel-feature-flags and how does it work?
- juststeveking/laravel-feature-flags is a lightweight, database-backed feature flag package for Laravel. Flags are stored as database rows and evaluated through a facade, a helper, Blade directives, and route middleware. It is designed for simple global on/off checks rather than user-level segmentation.
- How do I install juststeveking/laravel-feature-flags in a Laravel app?
- Install it with Composer, then publish the package's config and migration files and run migrate. Publish order matters because you need both the config and the features table in place. After that you create flag rows through the package's Artisan commands before branching on the facade in your application.
- Which Laravel versions does juststeveking/laravel-feature-flags support?
- The 1.4.0 release, dated 2024-03-13, was a Laravel 11 compatibility update contributed by a community PR. That release note covers compatibility only, so confirm the PHP version matrix and the maintainer's policy on future Laravel majors before standardizing. Treat a single compatibility release as an ecosystem signal, not a guaranteed maintenance cadence.
- How do I enable or disable a feature flag from code or Artisan?
- The package exposes feature flag management through Artisan commands for creating, enabling, and disabling flags, and through its facade for code-level checks. Because flags are database rows, the commands are effectively writing state to your features table. Check the package's command signatures in your installed version before wiring them into deployment scripts.
- How do I check a feature flag in controllers, Blade views, and routes?
- You can gate application logic with the facade or helper, use the package's Blade directives in views, and protect routes with the provided middleware. All of these read from the same in-process flag store backed by the database. An unknown flag resolves to inactive, so a typo or missing row will usually look like a disabled feature rather than an error.
- Why is my Laravel feature flag not working after I enabled it?
- The two most common causes are cached flag state and missing database rows. Flag state is cached, so a toggle may not take effect until the relevant cache is cleared. Fresh environments and CI runs start with everything off unless you seed flags or use an idempotent firstOrCreate. Also confirm the flag name matches exactly, because unknown flags resolve inactive.
- Does this package support per-user, percentage, or account-based feature targeting?
- No. This package is a global, in-process flag store that answers whether a feature is on for everyone right now, not whether it is on for a specific user or account. Per-user, percentage, or account-based targeting is the territory of Laravel Pennant or a custom resolver. Treating this package as a segmentation engine is the most common and most expensive misread.
- How should I seed feature flags for fresh environments and CI?
- Because flags are database rows, every fresh environment and CI run starts with all flags off unless you create them. Wire a deploy-time seeder or an idempotent firstOrCreate call into your integration checklist so environments do not silently lose features. This is an inherited obligation of database-backed flags, not a package defect.
- Is juststeveking/laravel-feature-flags safe to use in production?
- The technical risk is moderate-low and weighted toward maintenance and governance. It is a single-maintainer dependency in the request path, mitigated by its MIT license and small codebase, but supply-chain review should happen early. Unknown flags fail safe by resolving inactive, which is the right default but hides typos. There are no audit history, RBAC, or approval workflows, so flipping a production flag should be permissioned like a deploy. Verify caching behavior and test coverage before standardizing.
- How does it compare to Laravel Pennant and other feature flag alternatives?
- Choose this package when your flag consumers are exclusively PHP code inside a Laravel monolith and you want a small, auditable layer with no third-party vendor in the request path. Choose Laravel Pennant or a custom resolver when flags must be evaluated per user, per account, or by percentage. It also does not fit if flags must be read by mobile clients, edge workers, or non-PHP services.