Test Application Laravel Package

Product Decisions This Supports

• Plugin/extension compatibility strategy: If your roadmap includes shipping Sylius plugins or extensions to merchants, sylius/test-application gives your team a standardized skeleton to validate that code works across multiple Sylius releases before committing to a support matrix. The v2.2.0-ALPHA.1 release confirms the operating model: the project maintains parallel branches (2.0, 2.1, 2.2) with routine upmerges, so "multi-version testing" means adopting a branch-per-Sylius-version harness, not a single artifact that abstracts versions away. Plan your CI matrix around branches, not around one pin.
• Build vs. buy for test infrastructure: Rather than maintaining bespoke test scaffolding for each Sylius version your product targets, this package centralizes that environment. Still a "buy" (adopt) decision—MIT-licensed, cheap, reversible—but budget a small recurring cost for branch tracking and upmerge-driven churn.
• Support-matrix and release-gating decisions: Directly supports defining which Sylius versions you officially support and automating regression gates in CI. The explicit "lock Sylius version to 2.2" change in this release is exactly the mechanism you would replicate per branch; it also tells you the maintainers intend to track new Sylius minors promptly, which shortens the lag between a Sylius release and your ability to test against it.
• Roadmap risk for multi-version products: If your product must run on both LTS and current Sylius branches, this is a concrete enabler. If you only target one pinned version, the value proposition collapses—and note this release is an alpha for a not-yet-final Sylius line, so it is a signal of forward coverage rather than something to standardize on today.
• Ecosystem positioning: For a platform/agency business, using the canonical test app improves credibility with the Sylius community and simplifies onboarding of contributors who already know the standard layout. Continued maintainer investment (including a small but real DX fix—Twig default_path configuration—and automated upmerges) is evidence the project is not abandoned.
• Not a customer-facing feature: This is developer infrastructure. It does not unlock user-facing capabilities; it reduces engineering cost and defect risk. Roadmap impact is indirect (faster, safer plugin releases) rather than a line item customers will see.

When to Consider This Package

Adopt when:

• You maintain one or more Sylius plugins and need to prove they work across several Sylius versions without building a test app per version—accepting that this means checking out and maintaining one branch per Sylius line.
• You have a CI pipeline (GitHub Actions, GitLab CI, etc.) and want a reproducible, updatable fixture application to run integration tests against, with a branch strategy that mirrors your support matrix.
• Your team already uses Sylius/Symfony conventions—the package assumes familiarity with the Sylius stack, Composer, and Symfony test tooling; onboarding cost is low only for teams already in that ecosystem.
• You can tolerate a young, thin dependency. Small star count and no direct dependents remain true; the maintainer is Sylius core and the commit cadence is healthy, so treat it as a convenience harness, not a load-bearing platform dependency.
• You are comfortable tracking pre-release branches. The current head is an alpha targeting Sylius 2.2; pin to a stable branch (2.0/2.1) for production plugin CI and evaluate 2.2 separately.
• You want MIT-licensed tooling with no commercial or licensing friction.

Look elsewhere when:

• You run a single, pinned Sylius storefront. The multi-branch value is wasted; a standard Sylius skeleton is simpler.
• You need vendor-backed SLAs or long-term support guarantees. Adoption is still thin; plan to fork or vendor the harness if it becomes critical.
• You need a production-grade end-to-end test framework. This is a test application environment, not a testing framework—pair it with your own PHPUnit/Behat/Playwright stack.
• Your team is not on Sylius/Symfony. The learning curve outweighs the benefit; adopt only if plugin work is a real revenue line.
• You need a single dependency that spans all Sylius versions out of the box. This project deliberately pins one Sylius version per branch; if maintaining parallel branches is unacceptable, look at building your own matrix instead.

Adoption posture: Pilot on a non-critical plugin's CI before standardizing, using a stable branch. Treat it as an internal convenience with a fallback plan (fork or swap to a plain Sylius skeleton) if maintenance stalls. Watch the alpha→stable path for 2.2 to decide when to add that line to your tested matrix.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed testing harness from the Sylius ecosystem that lets our engineers verify plugin/extension work against multiple Sylius versions from a shared, community-standard setup. The latest release shows the maintainers actively tracking Sylius 2.2 alongside 2.0 and 2.1, which is exactly the multi-version coverage that protects revenue from merchants on older releases. Cost is near zero and the downside is contained—we can replace it with a plain test app if it's abandoned. Two caveats: adoption is still low, so we should pilot on one plugin first, and the newest line is an alpha, so we won't put it in a release gate until it stabilizes.

For engineering: sylius/test-application gives us a version-agnostic-by-branch Sylius environment we can wire into CI to run integration tests across supported Sylius versions. The v2.2.0-ALPHA.1 release adds a Twig default_path config fix, locks the branch to Sylius 2.2, and lands routine 2.0→2.1→2.2 upmerges—confirming the maintenance model we'd depend on: one branch per Sylius line, kept in sync by automation. That removes the "one bespoke test app per Sylius version" tax and keeps our scaffolding aligned with community conventions. It is not a test framework—it's the app under test—so it complements, not replaces, PHPUnit/Behat. Recommended next step: spike integration into one plugin's pipeline on a stable branch, measure flakiness and branch-upgrade effort, and trial the 2.2 alpha in a non-gating job. Keep a fork-and-own fallback documented.