Suite Tags Extension Laravel Package

Technical Evaluation

Architecture fit: The first TPM action is to correct the premise: despite the "tags" naming and the description text describing tag entities, admin tools, and Doctrine querying, the primary source assessment establishes this is a Behat Testwork extension — a dev-time filter that routes Gherkin scenarios into named suites (api, ui, admin) based on tags in behat.yml. There is no service provider, no Eloquent model, no migration, and no runtime footprint in a Laravel application. It touches only the acceptance-test layer, and only if the team runs Behat at all. Teams on PHPUnit/Pest alone get zero value.

Integration feasibility: Mechanically easy and cheap to trial — composer require --dev, a YAML block under extensions:, tags on feature files. The cost is not installation, it is verification: with 2 stars, 0 dependents, and no documentation beyond the source, the config key names (suite_tags vs. tags vs. nested maps) must be read out of configure() before anyone trusts a snippet. A mis-keyed block fails silently in Behat with no warning, which converts a 30-minute trial into an afternoon of debugging if unmanaged.

Technical risk: Moderate-to-high for a dependency, low for a throwaway trial. The extension was written against Behat 3.x and shows no activity; Behat's Suite/Filter internals have moved across majors, so an upgrade can break the filter without a clear error. Secondary risk is behavioural rather than technical: the suite filter ANDs with CLI --tags, producing "zero scenarios matched" in CI while the same command passes locally.

Key questions:

• Do we actually run Behat, and does suite routing solve a measured problem (CI wall-clock, duplicated config) that --tags or multiple profiles would not?
• Which Behat version are we pinned to, and does the extension's extension class still satisfy that version's Extension interface?
• What is the confirmed config schema, and does it support per-scenario overrides the way we expect?
• What is the licence, and is the source small enough to vendor inline if upstream goes dark?
• Is the description in our package metadata simply wrong? If we are scoring this as a tagging capability, the score is built on a false premise and should be re-run.

Integration Approach

Stack fit: Narrow but real. The fit is "Laravel app + Behat acceptance suite + GitHub Actions (or equivalent) matrix." The extension does not participate in application architecture, so the usual Laravel questions — service container, config publishing, package discovery, queue/events — are all irrelevant. Frame this to stakeholders as CI test-tooling, not a product capability; it does not deliver tagging features to users.

Migration path: There is no data migration and no schema change, which is the main argument in its favour. The migration is test-suite restructuring: tag feature files by suite, split the CI job into a matrix, and retire the duplicate behat-api.yml-style configs. Blast radius is confined to CI; rollback is deleting the YAML block and the dev dependency. Contrast this with the "tag entities and Doctrine querying" framing, which would imply an irreversible data model — it does not exist here.

Compatibility: Pin Behat explicitly in composer.json and treat any Behat major bump as a re-evaluation trigger. Confirm the Symfony Config component constraint resolves against the app's existing Symfony packages even in a Laravel-only project, since the extension inherits that dependency. Treat missing compatibility statements as a reason to spike, not to block — the code surface is one extension class.

Sequencing:

1. Reconcile the artifact: confirm the real package is the Behat suite-tag filter and correct the internal record and any score derived from the tagging description.
2. Establish a baseline: current CI duration, number of duplicated Behat configs, PR feedback time.
3. Read src/Behat/SuiteTagsExtension.php and any Configuration.php to lock down the config schema.
4. Branch-local spike with two suites (api, ui) and a CI matrix; measure wall-clock delta.
5. Decide adopt / inline-fork / drop. If the only need is skipping slow scenarios, --tags already does it and this package is unnecessary.
6. If adopted, add the dev dependency with a pinned version and a documented owner.

Operational Impact

Maintenance: Dev-only, so production risk is nil, but ownership is entirely internal. With no upstream activity and no dependent base, assume the team may need to copy SuiteTagsExtension.php into tests/Behat/ and register it locally — a small, well-bounded fork that removes the unmaintained dependency. Budget that as the likely end state rather than a contingency.

Support: None to speak of. There is no vendor relationship, no issue backlog signal, and no community knowledge to search. The mitigating factor is size: the whole thing is readable in one sitting, which is a materially better position than an unmaintained package with a large hidden surface. Assign a named engineer as owner and document escalation as "read the source."

Scaling: Runtime cost is negligible; the extension contributes a bootstrap filter. Scaling questions are really about the test suite: tag cardinality per suite, how many CI shards, and whether the @javascript mapping silently pulls browser scenarios into fast API jobs. Keep the suite tag map small and semantic — api/ui — and push selection concerns like @slow and @flaky into --tags, or the filter tree becomes hard to reason about as the suite grows.

Failure modes:

• Silent config no-op from a wrong key name under extensions:.
• Suite filter ANDed with CLI --tags, yielding zero scenarios in CI only.
• Tag inheritance: feature-level tags propagate and a scenario cannot un-tag itself; the fix is moving the scenario to its own feature file.
• Behat upgrade breaking the filter against moved Suite/Filter internals.
• Phantom CI failures when @javascript drags API-oriented scenarios into the UI job. Mitigations are cheap: --dry-run in the pipeline, an assertion that each suite matches a non-zero scenario count, and a pinned Behat version.

Ramp-up: For a team already writing Gherkin, an hour. For Laravel developers new to Behat, the ramp-up is Behat itself — suites, profiles, tag expressions, extension registration order — not this package. Do not staff this as a feature project; staff it as a CI hygiene ticket with a single owner and a half-day time box.