Sylius Feature Flag Bundle Plugin Laravel Package

Technical Evaluation

Architecture fit. This is a Sylius-specific plugin, not a general Laravel package despite the PHP/Laravel framing in the assessment brief. It wires em411/feature-flag-bundle into Sylius by promoting feature flags to a Doctrine-backed Sylius resource, exposed in the admin grid, and registering a high-priority Doctrine provider in the flag resolution chain. It is only viable if the target application is a Sylius storefront already using (or willing to adopt) the ajgarlag/em411 feature-flag bundle stack. For a plain Laravel or non-Sylius Symfony app it is not applicable without significant rework.

Integration feasibility. Mechanically straightforward for a Sylius shop: composer require, register two bundles in config/bundles.php, import admin routing, and run the Doctrine schema migration. The resource-based admin CRUD is idiomatic Sylius, which reduces bespoke code. The real question is whether the resolved dependency graph (Sylius version, Symfony version, Doctrine) can actually be satisfied by composer on the target project.

Technical risk (high).

• Stated compatibility is stale. Tested only on PHP 7.4–8.1, Sylius 1.8+, Symfony 4.4. Symfony 4.4 and PHP 7.4 are both EOL; current Sylius lines (1.12+, 2.x) run Symfony 5.4/6.x and PHP 8.1+. Expect constraint conflicts or untested behavior on any modern Sylius.
• Community signals are effectively zero. 0 stars, 0 dependents, a namespace that reads as a single maintainer, and no evidence of third-party production use.
• Provider precedence semantics are subtle. The Doctrine provider sits at "high priority" so a DB flag silently overrides a @AsFeature code flag of the same code. That is a powerful and easy-to-misuse behavior in production and should be treated as a governance concern, not just a config detail.
• Release date anomaly. A "last release" of 2026-05-26 against an EOL support matrix warrants verification of what was actually released and against what CI matrix.

Key questions before adoption.

1. What are the exact composer.json constraints on sylius/sylius, symfony/*, and doctrine/orm, and do they resolve on our target Sylius version?
2. Who maintains em411/* and ajgarlag/feature-flag-bundle, and what is the security disclosure path?
3. Is the high-priority DB override intentional and documented, and can we scope/tenant flags (or is it global toggle only)?
4. Does the admin grid enforce Sylius RBAC, and are changes audit-logged?
5. What is the upgrade story if Sylius 2.x is on the roadmap?

Integration Approach

Stack fit. Assume Sylius ~1.8–1.11 on Symfony 4.4/5.x as the only credibly supported band. Verify against the actual composer.json; do not assume. If the storefront is on Sylius 1.12+/2.x, treat this as a research spike, not a drop-in.

Migration path.

1. Resolve dependencies in a branch; confirm no version conflicts.
2. Register Ajgarlag\FeatureFlagBundle and Em411\SyliusFeatureFlagPlugin.
3. Import admin routing under the Sylius admin prefix.
4. Generate and review the Doctrine migration for the flag table; apply in staging first.
5. Seed a small set of flags; confirm the provider priority and override behavior.
6. Decide whether existing @AsFeature code flags migrate to DB or stay code-owned — the high-priority provider means DB silently wins, so do not run both for the same code without a rule.

Compatibility. Pin exact versions in composer.lock. Add the package behind a feature branch and run the full storefront test suite (checkout, admin, API) — a Sylius plugin touching admin resources and Doctrine can affect fixtures, serialization, and grid caching.

Sequencing. Land behind a kill switch: adopt the flag bundle without the Sylius plugin first (code-driven flags), then add admin-managed flags for a narrow, low-blast-radius surface (e.g., one non-critical UI toggle), then broaden. Do not put pricing, checkout, or payment gates behind this until the audit/override behavior is proven.

Operational Impact

Maintenance. Bus factor of one, no downstream dependents, and an EOL-leaning support matrix. Budget for a fork if upstream stalls; MIT makes that legally trivial but operationally non-free (you own the CI and Sylius upgrade treadmill). The "last release 2026-05-26" date should be reconciled with the stated PHP/Symfony matrix before trusting release cadence.

Support. README-only documentation; no community forum, no known production users. Internal ownership must be named. Expect to read the source to answer provider-priority and resource-configuration questions — a few hours, not weeks, given Sylius familiarity.

Scaling. DB-backed flags resolved per check can add read pressure; if the provider queries on each flag evaluation, expect per-request overhead under load. Mitigate with request-level caching and a small flag count. Admin grid is standard Sylius and scales like the rest of the admin.

Failure modes to plan for.

• DB unavailable → flag resolution fails. Decide fail-open vs fail-closed per flag; do not let a DB outage silently enable a half-built feature.
• Silent override. A DB flag overriding a @AsFeature with the same code is an easy footgun; enforce a naming convention or forbid code flags for DB-managed codes.
• Migration drift. Schema changes on Sylius upgrade can break the resource mapping; treat as a tracked upgrade task.
• Stale flags. No lifecycle management in the README — orphaned flags accumulate and become permanent "temporary" toggles. Add a review cadence and ownership per flag.
• RBAC gaps. Confirm admin grid respects Sylius roles; otherwise any admin can flip production behavior.

Ramp-up. Low for a team already fluent in Sylius resources and Doctrine; moderate-plus for everyone else. Estimate one engineer-day to spike dependency resolution and one to two days to wire, migrate, and validate in staging — contingent entirely on the composer constraints resolving. Recommendation: conditional go for evaluation on a Sylius ≤1.11 shop; no-go for production-critical gating or Sylius 2.x until upstream compatibility and maintenance are confirmed.