Weave Code
Toggle Bundle Laravel Package
landingi/toggle-bundle
A Symfony bundle for managing feature toggles, letting you enable or disable application features through configuration without changing code. Useful for gradual rollouts, A/B testing, and safely shipping work in progress.
landingi/toggle-bundle is a Symfony bundle for adding feature toggles to your application. It offers a lightweight way to define toggles and check whether a feature is enabled, helping teams ship code behind flags and control functionality without extra branching complexity.
- Simple toggle configuration for Symfony apps
- Convenient service integration for checking feature state
- Runtime feature gating for safer releases
- Keeps toggle logic separate from business code
Frequently asked questions about Toggle Bundle
- Is landingi/toggle-bundle a Laravel package?
- No. Despite being listed among Composer packages you might evaluate for a Laravel app, this is a Symfony bundle: it ships a Bundle class, a dependency-injection extension, and compiler passes rather than a Laravel service provider, config/toggle.php file, or facade. There is no Illuminate dependency and no Laravel-facing API. If your stack is Laravel, the architectural fit is poor and adopting it becomes a port, not an integration.
- Can I install landingi/toggle-bundle in a Laravel application?
- Composer may resolve it, but you get nothing Laravel can usefully wire up: no auto-discovered provider, no publishable config, no container bindings registered the Laravel way. You would have to manually instantiate Symfony services and replicate the bundle's compiler-pass logic inside your app. The effort exceeds simply writing account-scoped toggles yourself. Use Laravel Pennant or a small internal service instead.
- What Laravel versions does this package support?
- None officially. The package declares no illuminate/* constraints, has no Laravel documentation, and was last released in April 2021 at version 0.x, well before Laravel 10 and 11. It targets the Symfony 4/5 and PHP 7.4/8.0 era. Treat any Laravel compatibility claim as unverified until you read composer.json and the source.
- Where does landingi/toggle-bundle store feature flags?
- This is not documented anywhere in the available metadata or README, and that matters because the value of any toggle library lives in its decision source. Flags could come from static config, a Doctrine table, or a remote flag service, and each choice changes the failure model completely. Read the source before assuming, especially if you are evaluating it for production.
- How does the bundle resolve the current account when checking a feature?
- The package describes checking features for a given account, but the injection mechanism is not published: it could require your entity to implement an interface, use a request listener, or rely on a global. Until you inspect the code you cannot know whether it maps cleanly onto your own Account model. Plan for an adapter if you proceed.
- What PHP and Symfony version constraints does landingi/toggle-bundle have?
- Expect PHP 7.4/8.0-era constraints and Symfony 4/5 requirements given the April 2021 last release. Before committing, run composer why-not php 8.3 and composer why-not symfony/framework-bundle in your project to see exactly what blocks installation. On a modern PHP 8.3 and Symfony 7 stack it will very likely fail to resolve.
- Is landingi/toggle-bundle actively maintained?
- There is no visible activity since April 2021: no security policy, no CI badge, no issue triage, and zero dependents to copy a usage pattern from. It appears to be an internal extraction from Landingi's own monolith, published under MIT at 0.x. Assume you are forking on day one rather than consuming upstream fixes.
- What are the alternatives to landingi/toggle-bundle for Laravel?
- Laravel Pennant is the first-party option, actively maintained, with scoped features built in. For hosted flag management you can look at Unleash, Flagsmith, or LaunchDarkly, all of which document their Laravel integration. For a single is-feature-X-on-for-account-Y check, a roughly 150-line internal service is often sufficient and easier to test.
- How should I test feature toggles in a Laravel application?
- Define your own interface, for example FeatureResolver::isEnabled(string $flag, AccountContext $ctx): bool, and never let a third-party toggle API reach application code. In tests and local development, bind a trivial config-driven implementation behind that interface so flag state is deterministic in CI. This also gives you a clean swap path if you later replace the implementation with Pennant or a hosted service.
- Is it safe to run landingi/toggle-bundle in production?
- Feature flags sit on the authorization path of every request, so a defect here is a permissions or availability incident rather than a cosmetic bug. With no maintenance, no documentation, unknown flag storage, and unknown account resolution, the technical risk is high. If you must use it, wrap it behind your own adapter with a config-driven fallback so an upstream failure cannot silently flip flags.
Weaver
How can I help you explore Laravel packages today?