Feature Toggle Bundle Laravel Package

Product Decisions This Supports

Feature toggles are a delivery-risk tool, not a product feature — the value is in the decisions they unblock, not in the library itself.

• Release vs. launch decoupling. Dark-ship code behind a flag, then decide when to expose it. This separates "engineering is done" from "GTM is ready" and allows staged exposure by cohort, plan tier, or region without a redeploy.
• Build vs. buy for experimentation. A toggle layer is the minimum viable substrate for A/B tests and progressive rollouts. If you're weighing LaunchDarkly, Split, or Unleash, this package is the "build" baseline you compare against — but it provides only the toggle primitive, not targeting rules, analytics, or an audit trail.
• Kill-switch and blast-radius decisions. A flag you can flip in seconds is cheap insurance for risky migrations (new checkout, new search backend, pricing changes). PMs should own the list of "what must we be able to turn off instantly?" — this package gives engineering the mechanism to honor that list.
• Roadmap hygiene. Perpetual flags are both technical and product debt. Adopting a toggle library forces a conversation about flag ownership and expiry, which is a roadmap-level commitment, not a sprint task.
• Use cases that fit: internal dogfooding gates, beta/waitlist access, per-tenant entitlements, gradual percentage rollouts, and decoupling trunk-based development from customer-visible release.

Critical caveat for the decision at hand: despite the package description advertising a "Laravel package," the repository is a Symfony 2 bundle — a thin DI wrapper around JoshuaEstes/FeatureToggle, with no illuminate/* support. Symfony 2.x reached end-of-life in November 2018. With zero stars and zero dependents, there is no community to lean on for security patches or compatibility work. If your stack is Laravel, this cannot be dropped in; you would be writing your own service provider against the underlying library, or evaluating a maintained alternative.

When to Consider This Package

Adopt only under a narrow set of conditions:

• You run a legacy Symfony 2 application that is not being upgraded in the near term, and you need a toggle abstraction with minimal integration effort.
• You want the vendor-neutral FeatureToggle library interfaces (a FeatureManager, named toggle strategies) and are comfortable writing your own container wiring — in which case, depend on the library directly rather than the bundle.
• You need something very small and self-hosted: no SaaS dependency, no per-seat cost, no external network calls in the request path.
• You accept that you are taking on maintenance ownership. Treat this as "vendoring a pattern," not "adopting a supported dependency."

Look elsewhere — or build the ~100 lines yourself — if any of the following are true:

• You're on Laravel. This is a non-starter without a custom service provider. Laravel-native options (Pennant, or a simple config/DB-backed flag service) serve you better.
• You need targeting and experimentation. No percentage rollouts with sticky bucketing, no user-attribute targeting, no mutual exclusion between experiments, no results analysis. That's a platform decision, not a library decision.
• You need governance. No audit log of who flipped what and when, no approval workflow, no scheduled or automated rollback, no alerting on flag-state drift. For anything touching revenue or compliance, that's disqualifying.
• Security or procurement review is in play. An unmaintained Symfony 2 bundle with no dependents will not survive a modern dependency-scanning gate, and rightly so.
• You need multi-language or edge evaluation. Flags evaluate in PHP only; no client-side SDKs, no CDN-edge targeting.

How to Pitch It (Stakeholders)

To executives — the honest framing: "This is not a vendor we should standardize on. It's a years-old Symfony 2 integration with no adoption and no maintainer activity, and our stack is Laravel. Building on it would create a dependency we'd have to own and eventually rip out."

What the evaluation is actually worth: the exercise surfaced a real gap — we have no consistent way to dark-launch features, run controlled rollouts, or kill a bad release without a redeploy. That gap costs us engineering velocity and increases incident blast radius. The decision is whether to close it with a managed platform (LaunchDarkly/Unleash — cost, governance, targeting included) or a lightweight in-house flag service (cheap, but we own expiry discipline and audit tooling).

To engineering: "The underlying FeatureToggle library's interface design — a manager, named toggles, pluggable strategies — is worth borrowing from. The Symfony 2 bundle wrapper is not worth adopting, and it won't install cleanly against modern Laravel/Symfony components anyway. If we go in-house, we implement the same shape as a Laravel service provider in roughly a day, with tests, on a stack we can actually patch."

Recommended next step: treat this as a rejected candidate with a useful reference implementation, and spend one spike sizing an in-house toggle service (or Pennant adoption) against a three-month Unleash trial. Decide on governance requirements — audit trail, targeting, sticky bucketing — first; those, not the library, determine the answer.