Test Application Laravel Package

Technical Evaluation

• Architecture fit: Unchanged at the core: this is a Sylius (Symfony) package, not a Laravel one. Sylius bundles, Symfony DI, Doctrine, and the Sylius plugin model do not translate to Laravel. If we maintain Sylius plugins, it fits the "throwaway test application" slot — a host app used to exercise a plugin under test, never a runtime dependency of a product. v2.2.0-ALPHA.1 confirms the project is explicitly scoped to a single Sylius major per branch, which sharpens rather than changes that fit.
• Integration feasibility: High for Sylius plugin maintainers. The release cadence now visible in the changelog — branch cut for 2.2, 2.0 -> 2.1 and 2.1 -> 2.2 upmerges, and an explicit "Lock Sylius version to 2.2" commit — shows a deliberate per-major branch model maintained by the Sylius org itself (@SyliusBot, @Wojdylak). That is materially better than hand-rolling fixture apps per plugin. Feasibility remains low/zero for Laravel teams unless a Sylius workload exists.
• Technical risk: Blast radius is still low (dev-only, MIT, no production surface), and continuity risk is now downgraded: this is an org-owned Sylius repository with automated upmerge plumbing, not an orphaned 5-star project. Two residual risks replace the earlier one. First, this is an ALPHA pre-release — the 2.2 line is not yet a stable contract. Second, the earlier "version-agnostic" framing is now resolved in an important way: the package is version-agnostic within a Sylius major via per-major branches, and each branch pins hard to one Sylius version ("Lock Sylius version to 2.2"). That is a stronger design, but it means our support matrix is a branch-selection problem, not a constraint-resolution problem.
• Key questions:
  • Which branch do we track per Sylius major, and what is our policy for consuming ALPHA/BETA tags versus waiting for stable?
  • Does the 2.2 branch's locked constraint set actually cover the PHP minors we target, and is that recorded per release?
  • What is the promotion timeline from 2.2.0-ALPHA.x to a stable 2.2 tag, and does it gate our own Sylius 2.2 upgrade?
  • The new default_path Twig configuration option — does it diverge from our real application's Twig setup, and would that produce false-green test runs?
  • How does the upmerge bot behave when a patch lands only on an older branch, and who resolves conflicts on our fork if we carry local patches?
  • Does it replace or complement sylius/plugin-skeleton test tooling, and would adopting both create drift?

Integration Approach

• Stack fit: Classify by actual stack first. For Symfony/Sylius plugin repositories, treat it as a require-dev test-harness dependency wired into the CI matrix. For Laravel repositories, do not integrate — use it at most as a reference pattern for "version-agnostic test fixture," not as a dependency.
• Migration path: Introduce on a branch as require-dev, select the harness branch matching the Sylius major under test (2.1 branch today, 2.2 branch once we move), and migrate existing plugin test suites one Sylius major at a time. Keep the legacy harness in place until parity is demonstrated, then delete the old fixtures rather than running both indefinitely.
• Compatibility: Pin to stable tags only. Do not put 2.2.0-ALPHA.1 into a shared CI baseline — consume alphas solely in an isolated job that pre-validates an upcoming Sylius 2.2 upgrade, and promote to the shared pipeline only at a stable 2.2 tag. Validate the branch's locked Sylius constraint and PHP support against our own matrix inside CI. Record the Symfony/PHP constraint set each release asserts so upgrades are deliberate.
• Sequencing: (1) timeboxed spike on one low-risk plugin using the current stable branch; (2) measure CI duration and flake delta against the current harness; (3) codify the branch-per-Sylius-major mapping in pipeline config; (4) optionally stand up a non-blocking 2.2-alpha job to get early signal on the next major; (5) roll out to remaining Sylius repos in order of plugin criticality; (6) re-evaluate on each Sylius major and on the 2.2 stable tag.

Operational Impact

• Maintenance: Production operational surface is nil because this is dev-only. Ongoing cost is branch lifecycle management in CI: each Sylius major brings a new harness branch, and we must move pipelines across deliberately rather than float. Expect to bump this whenever Sylius or PHP majors move. Keep a fallback (vendored copy or a minimal homegrown fixture) so an alpha-stage or stalled branch never blocks a plugin's release.
• Support: Community-only, no SLA, no vendor. Org ownership by Sylius is a meaningful signal but not a support contract. Name an internal owner capable of debugging the test app, and do not design around upstream response time.
• Scaling: Cost scales with repository count, not traffic — each plugin repo pays to spin the test application in CI. Use Composer and build caching plus a trimmed matrix so a branch-per-major harness doesn't silently multiply CI minutes across the portfolio. Adding a speculative 2.2-alpha job multiplies this further; scope it to one or two representative plugins, not the whole estate.
• Failure modes: Alpha-stage branch treated as production-grade (the most likely mistake with this release); lag between a Sylius major and a stable harness tag, blocking plugin upgrades; upmerge-bot conflicts if we carry local patches on a branch; the test app drifting from real application configuration (false confidence in green builds) — newly relevant given the added default_path Twig option; Composer constraint conflicts with plugin dependencies. Mitigate with pinned stable tags, alpha consumption confined to non-blocking jobs, an internal mirror, and a thin contract test against a real application configuration.
• Ramp-up: Hours for a Symfony/Sylius engineer. Non-trivial and negative-ROI for Laravel-only teams — do not adopt it for its own sake. Document the "why" (CI matrix simplification and per-major branch mapping, not production scaffolding) so future maintainers don't mistake test fixtures for architecture, don't chase alpha tags into the shared baseline, and don't relitigate the Laravel/Symfony distinction.