Feature Bundle Laravel Package

Getting Started

This is a 2018-era Symfony bundle (not Laravel), archived since April 2018, with no dependents and no stars — treat it as reference code, not a dependency. The most honest first step is to read vendor/ruwork/feature-bundle/src before installing, because the API you'll find there is the only documentation you'll get.

Minimal setup on a legacy Symfony 3/4 app:

composer require ruwork/feature-bundle

Register it — AppKernel::registerBundles() on Symfony 3, config/bundles.php on Symfony 4:

new Ruwork\FeatureBundle\RuworkFeatureBundle(),

Then look in this order:

1. src/RuworkFeatureBundle.php — what it registers (services, Twig extension, compiler pass).
2. src/DependencyInjection/Configuration.php — the entire config surface. This is usually <50 lines and tells you whether features are defined in YAML or discovered by tag.
3. src/Feature/ (or src/Manager/) — the interface you'll inject. Expect something like a FeatureManagerInterface with isEnabled(string $name): bool and a FeatureInterface/Feature value object.

First use case: gate a half-finished page behind a flag.

if ($this->featureManager->isEnabled('new-checkout')) {
    // new path
}

Before writing any of that, confirm the package actually covers feature flags rather than domain-module registration — the name is ambiguous and the repo is too small for the README to be reliable.

Implementation Patterns

Inject the manager, never the container. Ask for the concrete interface in your constructor and let autowiring resolve it. If autowiring isn't configured (likely, given the era), add an explicit service definition or alias in services.yaml.

Config-driven flags per environment. The bundle almost certainly wires its state from the config tree. Keep the definitions in config/packages/ruwork_feature.yaml with environment overrides:

# config/packages/dev/ruwork_feature.yaml
ruwork_feature:
    features:
        new-checkout: true

This is the pattern that actually pays off day-to-day: every developer can flip a flag locally without touching code, and the prod file stays explicit.

Twig gating. If a Twig extension is registered, use it for template-level branches ({% if feature('new-checkout') %}) rather than passing booleans down from controllers. If it isn't registered, wrap the manager in a one-line Twig function yourself — that's a five-minute extension, not a reason to keep the bundle.

Tag-based feature discovery. If the bundle discovers features via a service tag, decorate your feature services and let the compiler pass collect them. Verify with:

bin/console debug:container --tag=ruwork.feature

Compose with Symfony's own primitives. For anything beyond static flags, prefer %kernel.environment% parameters or the ExpressionLanguage in your own service over this bundle's abstractions. A flag that depends on the current user is authorization, and belongs in a voter.

Testing. Set flags explicitly in config/packages/test/ruwork_feature.yaml and write one test that asserts a disabled feature's route/controller is inert. Don't mock the manager in unit tests — inject a stub implementation of the interface so you exercise the real gating logic.

Gotchas and Tips

It will not install on modern stacks. A 2018 bundle is pinned to php: ^7.1 and symfony/symfony: ^3.4|^4.0. On PHP 8 or Symfony 5+, Composer will refuse. Your options are --ignore-platform-reqs (fragile), a local fork with widened constraints (feasible for a tiny bundle), or reimplementing the feature in ~40 lines. For a package with zero dependents, the reimplementation is usually correct.

Compile-time vs runtime state is the critical distinction. If flags are resolved in a compiler pass and baked into the container, changing a flag requires bin/console cache:clear. On a container-based deploy (Envoy, Deployer, Kubernetes) that means a rebuild, not a config tweak. Check whether the manager reads a container parameter or a runtime source — this determines whether the bundle is viable for gradual rollouts at all.

Cache masking. After editing feature config, always cache:clear before debugging. On Symfony 4 the dev cache is separate from prod; testing a flag in the wrong environment is the most common false alarm with these bundles.

Auto-registration pitfalls. If the bundle relies on autoconfigure or a tag, the compiler pass silently skips untagged services and your feature reads as "always disabled" with no error. Run debug:container and confirm the tag exists on the service before assuming a logic bug.

No maintenance means no security patches and no PHP 8 fixes. Archived repos don't get CVE responses. Don't put it on a payment or auth path.

Extension points are limited but real. You can decorate the feature manager, implement your own resolver/strategy behind the interface, or replace the Twig function. Any of those is a legitimate "wrap it and swap it later" move if you're inheriting a codebase that already uses it.

Migration path. If you inherit this, the exit is mechanical: define a local FeatureManagerInterface with isEnabled(), keep the bundle's implementation behind an adapter, and route call sites through your interface. Then swap the adapter for a plain config-parameter reader — or a maintained toggle library if you need targeting and audit — without touching business code. Given the repo is archived with no users, plan to do that swap within the first sprint rather than carrying the dependency forward.