Scenariostate Behat Extension Laravel Package

Technical Evaluation

What it actually is. Unchanged. gorghoa/scenariostate-behat-extension is a Behat extension — not a Laravel package. It registers a ScenarioState service into Behat's service container and exposes it to step-definition contexts via a constructor argument resolver, giving step classes a shared, scenario-scoped object bag. Scope is small and single-purpose, and it has no relationship to Laravel's container, Eloquent, HTTP kernel, or Artisan. The only integration surface remains behat.yml plus the Composer autoloader.

What changed in v1.0.7. One community-contributed change: Symfony 5 component constraint compatibility (PR #38, credited to an external contributor). "SF5" almost certainly denotes Symfony 5 — Behat is built on Symfony DI, Console, EventDispatcher, Translation, and Yaml components, so a Symfony 5 constraint widening is the prerequisite for running under Behat 3.8+/Symfony 5-era stacks. Read literally, the note describes a dependency-constraint change, not a behavior change. It is a patch-level tag: no API change, no new extension points, no stated PHP 8 support, no stated change to the Behat version envelope, no test/CI evidence in the notes, and no support-policy statement. The integration shape documented in the prior review is untouched.

Architecture fit. Unchanged and still the primary finding. Fit with a PHPUnit/Pest-first Laravel team is zero; fit with a Behat-based acceptance layer that has multiple contexts handing off data is reasonable. If the evaluation was opened on the assumption that this is a Laravel package, it should be closed on that basis alone — the release does nothing to change that.

Integration feasibility. Mechanically unchanged, but slightly de-risked. Symfony component constraints are exactly the kind of thing that produces unhelpful Composer conflicts on a modern Behat install, and this release plausibly removes one. That is a real, if narrow, improvement to feasibility — it is not an improvement to viability, maintainability, or support.

Technical risk — downgraded from high to medium-high, not resolved.

• Maintenance status must be re-characterized, not erased. The prior assessment's "archived and unmaintained since 2020-10-07" is now factually superseded. The accurate description is "low-activity, sporadically maintained, with demonstrated receptiveness to external PRs." That is better than dead. It is not a maintenance commitment. A single merge after a multi-year gap is a data point, not a trend, and there is still no published support window, no security process, and no release cadence.
• The change does not address the actual compatibility gap. Widening a Symfony constraint does not fix PHP 8.x deprecations in the resolver path, nor does it commit anyone to Behat 3.13/3.14 internals. Constraint widening frequently ships without a CI matrix covering the newly permitted combinations — meaning we may now be allowed into configurations nobody has tested. The unverified envelope has arguably gotten wider, not safer.
• Ecosystem signal is unchanged. Zero dependents and ~33 stars. One PR does not create a body of production users, a Stack Overflow corpus, or an issue tracker worth mining.
• Build-vs-adopt math is unchanged. The functionality is still ~50–100 lines: a container service, a BeforeScenario reset hook, a resolver. Owning that code eliminates the entire compatibility, support, and upgrade obligation.
• Design-level risk is unchanged. A shared mutable state bag makes step ordering implicit and failure diagnosis harder. That trade must be a deliberate team decision.

Key questions (revised).

1. Does any team we care about actually run Behat? If not, terminate the evaluation — the release is irrelevant.
2. Does the SF5 constraint widening actually resolve a Composer conflict we have today, or does it merely widen an untested matrix? Run a real resolution against our pinned Behat and PHP.
3. Does the PR touch only composer.json, or does it also modify runtime code? Was it merged with CI evidence on the newly permitted combinations?
4. Which PHP and Behat versions must we support today and in 12 months, and does 1.0.7 move that envelope at all?
5. Given demonstrated but uncommitted maintenance, are we willing to fork and vendor under our own namespace — and if so, is that cheaper than building?
6. Does a named owner exist to pin this version and revisit it before the next Behat major?

Integration Approach

Stack fit. Unchanged. require-dev only, scoped to the Behat layer, never imported by application code, invisible to the Laravel runtime. If the org has no Behat layer, this terminates as "not applicable."

Migration path. Unchanged in sequence — register in behat.yml, introduce ScenarioState as a constructor dependency, migrate shared values one context at a time alongside the producing/consuming step, delete statics once unreferenced. The per-context reversibility remains the genuine advantage of the small API surface. The 1.0.7 patch does not alter this path and does not require a migration of its own.

Compatibility. Pin exactly — Symfony 5 compatibility means the acceptable-combination space is now broader, and broader is not safer without a matrix. Do not float constraints. Validate with a dry-run resolution against our pinned Behat and target PHP, and add a CI job across every PHP minor we intend to support. The realistic verified envelope is still PHP 7.x-era and Behat 3.x; PHP 8 remains unverified by the maintainer and must be verified by us or assumed broken.

Sequencing (adjusted at the decision gate only).

1. Confirm the Behat layer exists with a real state-sharing pain point (one day).
2. One-day spike: wire 1.0.7 into one feature and one context pair, on our pinned Behat and target PHP, and run the full suite.
3. In parallel, prototype the in-house equivalent to convert the build-cost estimate into a number.
4. Decision gate — now three viable outcomes rather than two: (a) build in-house and close the evaluation (still the default), (b) adopt upstream pinned at 1.0.7 with a named owner and a documented re-evaluation date, or (c) fork and vendor under our namespace.
5. If adopted, record the owner, the exact pin, a CI matrix, and a calendar reminder ahead of the next Behat major. If built, remove the package from consideration and document why.

The change makes option (b) defensible where the prior review effectively ruled it out. It does not make it preferable; the low opportunity score (11.38) and the small build cost still point at (a).

Operational Impact

Maintenance. The release slightly improves the starting position and leaves the obligation identical: we own this the moment we install it. The new evidence is that an outside contributor can get a constraint fix merged, which is a meaningful signal for a small library — a future Symfony or Behat compatibility break is plausibly fixable upstream rather than only in a fork. Do not convert that into an assumption of support. There is still no maintainer commitment, no release cadence, and no security response process. A named owner and a pin remain mandatory, and the "unowned dev dependency rots CI" failure mode is unchanged.

Support. Community-only and effectively dormant. The 1.0.7 thread is now the best available artifact in the issue tracker, which is a marginal improvement over an empty one. Debugging still means reading the source — short, and that remains the saving grace. Internal ramp-up docs must still be authored from scratch.

Scaling. Unchanged. The container is trivially cheap and will not bottleneck a multi-thousand-scenario suite. The scaling risk is cognitive: as more contexts share more keys, the state bag becomes an untyped, undocumented contract. Enforce namespaced keys, a typed accessor wrapper, and explicit per-scenario reset before the pattern sets.

Failure modes (one added).

• State leakage across scenarios if the reset hook is unwired or bypassed by a custom profile — order-dependent, flaky passes.
• Silent DI breakage on a Behat upgrade: extension fails to register, resolver returns nothing, steps fail with confusing type errors rather than a clear incompatibility message.
• Constraint-widening trap (new). 1.0.7 may declare compatibility with Symfony 5 combinations that were never exercised. A green composer update is not evidence of a working suite; only our CI matrix is.
• False comfort (new). A patch release on a five-year-quiet repository creates a perception of health that can suppress the fork-or-replace decision. Treat 1.0.7 as one merged PR, not a revival, and keep the re-evaluation date.
• PHP runtime drift on a CI image bump with no upstream fix available.
• Hidden coupling where a step passes only because a prior step populated a key, making features unrunnable in isolation.
• Abandonment creep: the dependency lingers in composer.json after the Behat layer is retired.

Ramp-up. Unchanged and low: an engineer familiar with Behat is productive in under a day, and the source reads end to end. The recurring cost is organizational — an owner for the pin, the fork decision, and the state-naming conventions — against roughly a hundred lines of avoided boilerplate.

Recommendation (revised). Build remains the preferred outcome. The 1.0.7 release is a genuine but narrow improvement — it converts "abandoned" into "sporadically maintained" and plausibly clears a Symfony 5 constraint blocker — and it is sufficient to justify a timeboxed spike against the pinned upstream. It is not sufficient to adopt without a named owner, an exact pin, a CI matrix covering the newly widened combinations, and a scheduled re-evaluation.