Ab Bundle Laravel Package

Technical Evaluation

Architecture fit — low, and the framing is wrong. jm/ab-bundle is a Symfony 2.x bundle, not a Laravel package. It is built around Symfony's DI container, kernel event listeners, and Twig template-loading overrides. There is no service provider, no Blade integration, and no illuminate/* dependency. Any Laravel adoption is therefore a port, not an install — the deliverable is a re-implementation of the variant-assignment and template-resolution pattern, with the bundle itself serving only as a reference design.

What the package actually does is narrow and legible: persist a variant choice per visitor (cookie/session), and resolve a template name to one of N versioned variants at render time. That is roughly a few hundred lines of coordination logic. The intellectual property is the pattern, not the code.

Integration feasibility — feasible only as a rewrite. The useful extraction targets are:

• Variant assignment strategy (random selection + persistence)
• Template resolution/override hook
• Experiment key → variant-set configuration

Each of these has a clean idiomatic equivalent in Laravel: a ViewFinder decorator or view-name resolver, a middleware for session/cookie binding, and a config-driven experiment registry. Effort is small — a spike plus a focused implementation, not an integration project.

Technical risk — high, and mostly non-technical in nature.

• Abandoned upstream. Symfony 2 reached end-of-life in 2018; the package has no releases, no security process, and no maintainer obligation. Its Composer constraints will not resolve on PHP 8.x or modern Symfony.
• Zero dependents, 23 stars. No downstream validation, no issue history to mine for known failure modes. The scoring in the brief (0.265 overall, 0.24 opportunity) is consistent with a package that is a design reference rather than a dependency.
• No observability. The bundle swaps templates; it does not record exposures or outcomes. An A/B capability without exposure logging cannot produce a lift estimate — it is a content-variant switcher, not a testing platform.
• Correctness gaps for production use. Cookie-only stickiness breaks for cookie-less and privacy-restricted users, causing variant churn and sample pollution. Interaction with full-page/CDN caching is unaddressed and is the classic source of variant bleed.

Key questions for the requesting team:

1. Is the requirement template variant swapping, or experimentation (assignment, exposure, metric attribution, significance)? Only the first is in scope for this package.
2. Which framework and version is the actual target — Laravel 10/11, or a legacy Symfony 2 app? This determines whether we port or discard.
3. Is per-user sticky assignment required across sessions and devices, or is per-session randomization acceptable?
4. Where is the rendered page cached — CDN, reverse proxy, response cache? Variant keying must be part of the cache key or the experiment is invalid.
5. What is the consent posture for the assignment cookie?
6. Who owns the code after delivery, and is there budget for that ownership?

Integration Approach

Stack fit. Treat as not installable on a modern Laravel or Symfony stack. Fit is limited to a legacy Symfony 2 application, and even there the PHP version constraint is likely the blocker. Recommended position: reference implementation only; do not add as a dependency.

Migration path (Laravel target). Four small components, each independently shippable:

1. Experiment registry — config file mapping experiment key → variant list and weights.
2. Assignment service — deterministic bucketing via hash of experiment_key + stable_subject_id (authenticated user ID, else a first-party visitor ID). Deterministic hashing is strictly better than the bundle's random-and-persist approach: it is idempotent, testable without mocks, survives cookie loss, and stays consistent across app servers.
3. View resolution — a ViewFinder decorator that first attempts {view}.{variant} and falls back to the base view, with the fallback logged rather than silent.
4. Exposure logging — an event or log line emitted once per subject per experiment, wired to whatever analytics store already exists.

Compatibility. No shared surface with the original: different container, different templating, different event model, different PHP baseline. There is no incremental migration from the bundle to the port — it is a clean build. Do not attempt a shim.

Sequencing.

1. Spike (1–2 days): read the bundle source, document its variant-resolution and persistence semantics, decide which behaviors are worth carrying forward. Deliverable: a one-page behavior spec, not code.
2. Assignment service + registry with unit tests covering distribution and stickiness.
3. View resolution decorator with explicit fallback behavior and cache-key implications documented.
4. Exposure logging before the first live experiment — this is a gate, not a follow-up.
5. First experiment behind a feature flag, on a low-traffic surface, with a rollback switch.

Do not sequence exposure logging after the first experiment ships. Retrofitting it invalidates the data already collected.

Operational Impact

Maintenance. Full internal ownership from day one. There is no upstream to patch, no CVE feed, and no maintainer to escalate to. Because the delivered artifact is our own code, this cost is bounded and predictable — which is the strongest argument for porting over forking.

Support. No vendor, no community, no SLAs. Support burden lands on the owning team and must be reflected in on-call scope. Expect questions of the form "why did this user see variant B twice" — answerable only if exposure logging is in place.

Scaling. Runtime cost is negligible: one hash, one lookup, one cookie read per request. The real scaling concerns are elsewhere:

• Template cache growth. Each variant is a separately compiled template; N variants across M templates multiplies cache entries and deployment artifacts.
• Template duplication cost. Variants are near-duplicate markup, so every UI change must be applied N times. This is the dominant long-term cost and the most common reason template-level A/B programs are abandoned. Plan to retire experiments and delete variants aggressively.
• Cache correctness over throughput. If pages are CDN-cached, variant must be part of the cache key or served via edge logic. Getting this wrong produces silently invalid results at any scale.

Failure modes to design against.

• Variant bleed via page cache — highest severity; produces wrong content and corrupt data.
• Silent fallback — missing variant template renders the base version; users are counted as exposed to a variant they never saw.
• Assignment churn — cookie loss or privacy modes reassign subjects, diluting measured effect toward zero.
• Sample ratio mismatch — weighting bugs that skew traffic split, detectable only with exposure counts.
• Template drift — variants diverge from the base over successive releases, causing rendering bugs unique to one arm.
• Dependency rot — if the bundle is installed on a legacy app, it pins the PHP/Symfony upgrade path indefinitely.

Ramp-up. Low for the code itself, moderate for domain judgment. An engineer can read the entire bundle in an afternoon. The harder skills are experiment design — assignment unit, exposure definition, metric selection, stopping rules — and those are not in the package. Budget for a statistician or analytics partner, not just an implementer.

Bottom line. The package is a reasonable 2013-era design sketch for template variant swapping and a poor foundation for a 2025 experimentation capability. Recommended decision: do not adopt; extract the pattern, re-implement deterministically, and invest the saved effort in exposure logging and cache-correctness, which are where the actual risk lives.