Feature Toggle Bundle Laravel Package

Technical Evaluation

Architecture fit. The naming in this repo is misleading and that matters for planning: hotflo/feature-toggle-bundle is a Symfony2 bundle, not a Laravel package. The Laravel-style description (Blade directives, middleware, config-driven flags) does not match the artefact — the code is a Bundle subclass plus a DI container extension, service definitions, and framework config. Laravel has no counterpart to any of that. What is reusable is the underlying JoshuaEstes/FeatureToggle library and its concept — a named toggle resolved against a context — and that concept is now available from a first-party source (Laravel Pennant). From a product perspective the deliverable here is a pattern reference, not an adoptable dependency.

Integration feasibility. Low without a fork, and the fork yields nothing Pennant does not already give us. A realistic spike: strip bundle wiring, re-express services as a Laravel ServiceProvider with a published config file, replace Symfony event-dispatcher/kernel hooks with Laravel equivalents, audit the transitive dependency set, and write tests. Estimate 3–5 engineering days for a proof of concept plus hardening — spent reproducing a capability the framework ships. Only worth it if there is existing Symfony2 code in the estate consuming this bundle; otherwise the correct move is to read it and move on.

Technical risk. High, and mostly non-technical. Symfony 2.8 went end-of-life in November 2018 and receives no security patches. The dependency graph almost certainly pins Symfony 2.x/3.x components, which will collide with Laravel 10/11/12's requirement on Symfony 6.x/7.x — Composer resolution likely fails before a line of integration code is written. Zero stars and zero dependents means no downstream validation against a modern runtime, no triaged issues, and no evidence the package works outside the author's original context. That combination will not survive a modern dependency-scanning gate in procurement or security review, and it shouldn't.

Key questions.

• What toggle taxonomy do we actually need — release toggles, operational kill switches, permission/entitlement flags, or experiment assignment? Each has different lifecycle, audit, and targeting requirements, and the answer decides whether a library is warranted at all.
• Is there live Symfony2 code in the estate consuming this bundle, or is this greenfield interest driven by the misleading description?
• Which specific decisions does a toggle layer unblock for us in the next two quarters — dark launches, cohort rollouts, per-tenant entitlements, kill switches on risky migrations? Without a named list, this is a solution hunting a problem.
• Do we require an admin UI, audit trail of who flipped what and when, approval workflow, or scheduled rollback? Neither this package nor its underlying library provides any of that.
• Who owns the fork if we proceed, and what is the deprecation path off it?
• Has Laravel Pennant, Unleash, or LaunchDarkly been evaluated against the same requirement with the same rigour?

Position. Do not adopt. Treat this as a rejected candidate with a useful reference implementation. The evaluation is still valuable because it surfaces a real gap — we have no consistent way to dark-launch, run controlled rollouts, or kill a bad release without a redeploy — and that gap costs engineering velocity and widens incident blast radius.

Integration Approach

Stack fit. Poor as packaged; workable only as a conceptual reference. Laravel Pennant (first-party, Laravel 10.37+) covers release toggles and feature gating with a Feature::active() API, pluggable stores, and zero third-party maintenance burden. Where targeting, percentage rollouts with sticky bucketing, or cross-service consistency are in scope, an Unleash-compatible backend is the stronger option. The library's core idea — a named toggle resolved against a context — is sound and worth borrowing; the bundle wrapper is not.

Migration path. If legacy Symfony2 consumers exist, do not port the bundle. Apply a strangler pattern: define a narrow internal contract — ToggleResolver with isActive(string $flag, array $context): bool — implement it once over Pennant, and add a second adapter that proxies to the legacy Symfony2 service during cutover. Call sites depend on the contract, never on either implementation, so the legacy adapter is deleted when the last Symfony2 process retires. This also gives us an escape hatch if we later move to a managed platform: swap the adapter, leave call sites untouched.

Compatibility. Treat as a hard blocker pending verification. Confirm composer.json PHP and Symfony component constraints against our runtime (PHP 8.2+ for Laravel 11/12). Even if constraints happen to resolve, untyped PHP 5-era code will emit deprecations and will not pass static analysis at our quality gate. Verification is a two-hour task, not a spike — do it first, before any design work.

Sequencing.

1. Define the toggle taxonomy and a naming convention before writing code. This decision outlives any library choice and is the one TPMs should own.
2. Specify the resolution contract, including explicit default-when-undefined semantics (fail-closed for entitlements, fail-open for kill switches — these are different answers for different flag classes).
3. Select the backend: Pennant for release toggles; Unleash if targeting or experimentation is in scope.
4. Build the adapter plus a thin test harness covering default, overridden, missing, and malformed-flag cases.
5. Migrate call sites behind the contract; instrument evaluation counts per flag to feed expiry decisions.
6. Add governance — named owner per flag, expiry date, cleanup cadence — before flag count grows. Retrofitting governance onto 200 flags is materially harder than starting with it.

Operational Impact

Maintenance. A fork is a permanent, unbudgeted liability: no upstream commits, no security advisories, no compatibility patches as PHP and Laravel advance. Every future framework upgrade becomes a manual audit of code we own but did not write, and the cost recurs annually rather than once. Against zero adoption signal, this is a poor trade.

Support. No vendor, no community, no issue history to search. The only escalation path is an internal engineer reverse-engineering a seven-year-old bundle — an unpredictable and poorly bounded support burden. Contrast with Pennant, where the answer is in the Laravel documentation and the maintainer is the framework team.

Scaling. Toggle evaluation is in-process and cheap, but naive implementations hit the store on every check, turning hot paths into a database round-trip per request. Whatever backend is chosen must resolve the flag set once per request and cache it; Pennant's scoped stores handle this, and a hand-rolled fork would need the same built and tested from scratch. Cross-service consistency needs a plan too — a cached in-process store lags flag changes by the cache TTL, which is unacceptable for kill switches during an incident.

Failure modes.

• Ambiguous defaults — a misspelled flag silently evaluating to off, disabling a feature in production with no error surfaced. This is the single most common production incident in home-grown toggle systems.
• Stale configuration — cache invalidation lag making kill switches slow to take effect exactly when speed matters.
• Toggle debt — flags outliving their feature, accumulating permanent branches and untested code paths. This is the dominant real-world cost and is a governance problem, not a library problem; it is the item that needs a PM owner.
• Evaluation divergence — different services resolving the same flag differently due to mismatched context or cache state.
• Fork drift — a patched local copy diverging from the original in undocumented ways, discoverable only during an incident.

Ramp-up. Low for anyone with Symfony experience, but the team is Laravel-oriented, so we would pay cognitive overhead to learn a foreign bundle convention for a capability the framework already exposes idiomatically. That overhead is recurring — paid on every onboarding and every new hire — not a one-time learning cost.

Recommended next step. Close this evaluation as a rejected candidate with a captured reference implementation. Spend a short spike sizing an in-house Pennant-based toggle service (roughly one engineer-day including tests) against a three-month Unleash trial, and decide the governance requirements — audit trail, targeting, sticky bucketing, cross-service consistency — first. Those requirements, not the library, determine the answer. Separately, capture the list of "what must we be able to turn off instantly?" as a standing PM-owned artefact; it is useful regardless of which backend we pick.