Laravel Pennant | Laravel 13.x - The clean stack for Artisans and agents

Laravel Pennant is a simple and light-weight feature flag package - without the cruft. Feature flags enable you to incrementally roll out new application features with confidence, A/B test new interface designs, complement a trunk-based development strategy, and much more.
First, install Pennant into your project using the Composer package manager:
Next, you should publish the Pennant configuration and migration files using the vendor:publish Artisan command:
Finally, you should run your application's database migrations. This will create a features table that Pennant uses to power its database driver:
After publishing Pennant's assets, its configuration file will be located at config/pennant.php. This configuration file allows you to specify the default storage mechanism that will be used by Pennant to store resolved feature flag values.
Pennant includes support for storing resolved feature flag values in an in-memory array via the array driver. Or, Pennant can store resolved feature flag values persistently in a relational database via the database driver, which is the default storage mechanism used by Pennant.
To define a feature, you may use the define method offered by the Feature facade. You will need to provide a name for the feature, as well as a closure that will be invoked to resolve the feature's initial value.
Typically, features are defined in a service provider using the Feature facade. The closure will receive the "scope" for the feature check. Most commonly, the scope is the currently authenticated user. In this example, we will define a feature for incrementally rolling out a new API to our application's users:
As you can see, we have the following rules for our feature:
The first time the new-api feature is checked for a given user, the result of the closure will be stored by the storage driver. The next time the feature is checked against the same user, the value will be retrieved from storage and the closure will not be invoked.
For convenience, if a feature definition only returns a lottery, you may omit the closure completely:
Pennant also allows you to define class-based features. Unlike closure-based feature definitions, there is no need to register a class-based feature in a service provider. To create a class-based feature, you may invoke the pennant:feature Artisan command. By default, the feature class will be placed in your application's app/Features directory:
When writing a feature class, you only need to define a resolve method, which will be invoked to resolve the feature's initial value for a given scope. Again, the scope will typically be the currently authenticated user:
If you would like to manually resolve an instance of a class-based feature, you may invoke the instance method on the Feature facade:
Feature classes are resolved via the container, so you may inject dependencies into the feature class's constructor when needed.
By default, Pennant will store the feature class's fully qualified class name. If you would like to decouple the stored feature name from the application's internal structure, you may add the Name attribute on the feature class. The value of this attribute will be stored in place of the class name:
To determine if a feature is active, you may use the active method on the Feature facade. By default, features are checked against the currently authenticated user:
Although features are checked against the currently authenticated user by default, you may easily check the feature against another user or scope. To accomplish this, use the for method offered by the Feature facade:
Pennant also offers some additional convenience methods that may prove useful when determining if a feature is active or not:
When using Pennant outside of an HTTP context, such as in an Artisan command or a queued job, you should typically explicitly specify the feature's scope. Alternatively, you may define a default scope that accounts for both authenticated HTTP contexts and unauthenticated contexts.
For class-based features, you should provide the class name when checking the feature:
The when method may be used to fluently execute a given closure if a feature is active. Additionally, a second closure may be provided and will be executed if the feature is inactive:
The unless method serves as the inverse of the when method, executing the first closure if the feature is inactive:
Pennant's HasFeatures trait may be added to your application's User model (or any other model that has features) to provide a fluent, convenient way to check features directly from the model:
Once the trait has been added to your model, you may easily check features by invoking the features method:
Of course, the features method provides access to many other convenient methods for interacting with features:
To make checking features in Blade a seamless experience, Pennant offers the @feature and @featureany directive:
Pennant also includes a middleware that may be used to verify the currently authenticated user has access to a feature before a route is even invoked. You may assign the middleware to a route and specify the features that are required to access the route. If any of the specified features are inactive for the currently authenticated user, a 400 Bad Request HTTP response will be returned by the route. Multiple features may be passed to the static using method.
If you would like to customize the response that is returned by the middleware when one of the listed features is inactive, you may use the whenInactive method provided by the EnsureFeaturesAreActive middleware. Typically, this method should be invoked within the boot method of one of your application's service providers:
Sometimes it can be useful to perform some in-memory checks before retrieving the stored value of a given feature. Imagine you are developing a new API behind a feature flag and want the ability to disable the new API without losing any of the resolved feature values in storage. If you notice a