- How do I install and configure edalzell/laravel-features?
- Install it with Composer using composer require edalzell/laravel-features, then publish the package config and create the features directory as described in the README. There is no infrastructure, runtime service, or external data store to provision. For brownfield apps, start by lifting one vertical slice into a feature rather than converting all of app/ at once.
- Which Laravel and PHP versions does laravel-features support?
- The authoritative support matrix is the package composer.json and README, so check those against your current major and your next-upgrade target before adopting. The TPM review recommends constraining to ^1.1 and treating 1.1.0 as the floor because it includes the seeder discovery fix and feature-scoped translations. Confirm the tagged support window for 1.0.x if you are already on an older release.
- How do I check whether a feature is enabled for a specific user or globally?
- The package exposes model methods for defining, toggling, and checking features, and it supports both per-user and global scopes. Use those APIs rather than querying feature tables directly so the package can apply its own resolution order. Keep the check close to the decision point, such as a controller, policy, or job, and add tests for both the user-specific and global cases.
- Can I use Blade directives to show or hide UI based on a feature flag?
- Yes, the package ships Blade directives for gating views, so you can conditionally render navigation, buttons, or whole sections without writing manual checks in every template. Treat Blade directives as presentation only and keep authorization and business rules in middleware, policies, or services. This avoids exposing privileged actions if a template is reused in a context where the flag check is bypassed.
- How do I protect routes with feature-flag middleware?
- The package provides middleware for gating routes and views, so you can attach it to route groups or individual routes. Register the middleware alias if your Laravel version requires it, then apply it alongside your normal auth and authorization middleware. Return a 404 or 403 consistently so disabled features do not leak their existence to users.
- How are feature dependencies and ordering handled, and can cycles be detected?
- Features can declare dependencies, and the package documents a dependency and ordering model, but cycle detection is a key question to verify in the docs and test suite before relying on deep chains. Implicit registration makes boot order and collision behavior less obvious when debugging. Keep dependency graphs shallow and add a test that boots all features in a clean application.
- What changed in laravel-features v1.1.0?
- v1.1.0 adds feature-scoped console commands (#107) and translations (#108), route group closures (#109), and fixes seeder discovery when seeders reference other seeders via ::class (#110). It is semver-minor and additive, but auto-loading a feature's translations can change runtime behavior if that feature already registered translations manually. Pin to ^1.1 and review override order before upgrading.
- What happens if two features register the same command signature or translation key?
- The TPM review flags this as unresolved: auto-registration is convenient, but collision behavior for duplicate command signatures and duplicate translation keys is not clearly fail-loud. Until you verify it, assume last-wins or override-order surprises and avoid duplicate names across features. Add a boot test that registers every feature and asserts artisan list output and translation keys.
- Is laravel-features safe with config:cache, route:cache, and optimize in production?
- Route group callbacks are evaluated at registration time, so route:cache should remain compatible, but arbitrary code now runs during route registration and deserves a review gate. Validate config:cache, route:cache, and optimize in a staging deploy before production. Also confirm whether feature discovery is cached and what the boot-time cost is at your expected number of features.
- Should I use laravel-features instead of nwidart/laravel-modules or a hand-rolled app/Modules folder?
- It is a native Laravel feature and module boundary with no new build tool, container, or deployment target, so it fits apps that are already Laravel-idiomatic. It overlaps with nwidart/laravel-modules and hand-rolled app/Modules loaders, so do not run two discovery systems over the same directories. Maintenance is a consideration: the v1.1.0 changes come from a single maintainer, so review CI and release cadence before depending on it for long-lived modules.