Suite Tags Extension Laravel Package

Product Decisions This Supports

• Test-infrastructure ROI, not product features. The strongest reading of the actual code (per the engineering assessment) is that sylius-labs/suite-tags-extension is a Behat extension that filters test suites by tags — not a domain tagging feature for Laravel models. The vendor blurb about "tag entities and resource associations" contradicts the code-level review and should be treated as unreliable until source is inspected. That reframing is the single most important product decision here: this is a developer-productivity / CI-cost lever, not a customer-facing capability.

• CI budget and cycle-time tradeoffs. The core decision it supports is whether to split a growing acceptance-test suite into independently runnable slices (e.g. fast API-only on every PR, browser/UI nightly) without duplicating .feature files or maintaining multiple Behat configs. Frame the value as PR feedback latency and CI minutes saved, which are measurable, rather than as a feature differentiator.

• Build vs. reuse for a ~thin filter. Because the package is a small filter over Behat's native tag system, the realistic options are: (a) adopt as a dev dependency, (b) copy the extension class into tests/Behat/ and own it locally, or (c) implement suite routing via CI matrix + --tags without any extension. A PM should force this three-way comparison explicitly; the "reuse" option has near-zero strategic moat.

• Roadmap placement. This belongs in engineering enablement / test-infrastructure hygiene, not the product roadmap. Its adoption signal (2 stars, 0 dependents, score 0.07) means it should never block a release or appear in a customer-facing narrative.

• Use-case validation. Legitimate fits: multi-suite Behat setups, per-suite CI jobs, fast local smoke loops. Poor fits: anything requiring per-suite hooks, sophisticated test orchestration, reporting/analytics on test results, or vendor-backed support.

When to Consider This Package

Consider it when:

• You already run Behat (in a Laravel project or otherwise) and have a features/ tree you want to slice into api / ui / admin suites by tag rather than by directory.
• Your pain is CI wall-clock time and duplicated config, and a one- to two-day spike is acceptable.
• The need is dev-only and low-risk — it never ships to production, so the blast radius of failure is limited to test tooling.
• Your team is willing to read the source first (SuiteTagsExtension.php, its configure(), and any spec//tests/), because docs are effectively absent and the published description does not match the code.
• You are prepared to fork-and-vendor the extension locally if it stops meeting Behat version compatibility.

Look elsewhere / do not adopt when:

• You actually need domain tagging (products, content, taxonomy) — that is a different problem, and the vendor description's claims about tag entities, admin tools, and Doctrine querying should not be relied upon without verifying they exist in code. Do not scope a tagging feature on the back of this package.
• You need vendor-backed support, a maintenance guarantee, or a compatibility matrix — none exist here.
• You run PHPUnit/Pest only — there is nothing to integrate; Behat is a prerequisite.
• You need per-suite hooks, driver switching, or advanced orchestration beyond tag-based filtering.
• You are on a newer Behat major version without a compatibility check; the extension was written against Behat 3.x and shows no activity.

Mandatory due-diligence gate before any adoption: confirm the real config key (silently ignored config is the documented trap), confirm Behat version support, confirm interaction with CLI --tags (filters AND together, a common "zero scenarios matched" CI failure), and confirm the description/code mismatch is fully understood by the team.

How to Pitch It (Stakeholders)

Executive summary: sylius-labs/suite-tags-extension is a small, unmaintained Behat test-suite filtering extension — despite a vendor description that misleadingly reads like a domain-tagging library. It lets teams route scenarios into separate test suites (e.g. fast API checks on every pull request, browser tests nightly) using tags, which can shorten PR feedback loops and cut CI spend. However, adoption is effectively zero (2 stars, 0 dependents) and documentation is thin, so it carries maintenance risk with no strategic upside. Recommendation: treat it as an internal engineering-enablement experiment, not a platform dependency. Budget a short spike to verify the real configuration and Behat compatibility, and prefer either a local vendored copy of the extension or a plain CI matrix with --tags if the spike shows friction. Do not use this package to justify or scope a customer-facing tagging feature — that would require a separate build decision informed by the code, not the marketing copy.