Sylius Static Contexts Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for context plumbing: StaticChannelContext and StaticLocaleContext solve a small but recurring problem — Sylius resolves channel/locale from the request, which doesn't exist in CLI commands, message-queue consumers, cron jobs, or test fixtures. This package is a thin, purpose-built adapter; the alternative is hand-rolling per-project context switching that every team reimplements and re-debugs. Adopt rather than build.
• Feature feasibility for async and headless flows: Any roadmap item involving queued emails, scheduled promotions, import/export commands, ERP/webhook sync, or API-only storefronts requires a deterministic channel/locale to be set outside a HTTP request. This release confirms the package is maintained against current Sylius v2 and Symfony 6.4/7.4, so it can be safely scoped into those roadmap items.
• Platform upgrade sequencing: v2.0.0 is effectively a signal that the Sylius v2 / PHP 8.2 / Symfony 6.4+ migration path is supported by this dependency. It becomes a line item in the platform-upgrade epic — and, importantly, a low-risk one, since the migration guide states no code changes are needed for consumers of the public API.
• Test-suite and multi-store strategy: The added test coverage for reset(), null-unsetting, DI registration, and tag priorities gives confidence for multi-channel/multi-locale stores where a leaked static context could silently serve the wrong locale. That reduces the risk profile of supporting many channels per deployment.
• Roadmap risk register: Choosing this package means accepting Sylius v2 as a floor. Projects still on Sylius v1 or PHP 8.1 are pinned to the 1.x branch, which should be logged as technical debt with an owner and a deadline.

When to Consider This Package

Consider adopting when all of the following hold:

• You run Sylius v2 on PHP 8.2+ and Symfony 6.4 or 7.4 — the new hard requirements. If you are on Sylius v1 or PHP 8.1, stay on 1.x; v2.0.0 will not install.
• You have non-HTTP execution paths that touch Sylius services: Messenger consumers, scheduled commands, data imports, fixtures, or functional/unit tests that need a channel or locale.
• You operate more than one channel or locale, where an unset or stale context would produce wrong-currency prices, wrong translations, or misrouted emails.
• Your team values small dependency surface: this is a narrow, single-purpose bundle, not a framework.

Look elsewhere or skip it when:

• Your app is purely request-scoped with a single channel and single locale — the request context already does the job and this adds indirection with no payoff.
• You need per-job context that varies at dispatch time with automatic propagation (e.g. serializing channel/locale into Messenger envelopes). Static context is a global; that's a design constraint, not a bug. Evaluate whether a middleware/stamp-based approach fits better before adopting.
• You require long-term support guarantees or vendor backing — this is a community bundle; the upgrade cadence follows the maintainer's own Sylius adoption, not your release calendar.
• You are not on Sylius at all — the interfaces and DI tags are Sylius-specific.

Also note the practical caveat: static/global context must be reset between jobs in long-running workers. The release adds tests around reset() and null-unsetting, which is a positive signal, but the responsibility for calling it remains yours. Treat that as an engineering requirement, not an optional nicety.

How to Pitch It (Stakeholders)

For executives: This is a routine maintenance release of a small utility library that lets our background jobs, scheduled tasks, and API endpoints correctly resolve which store and language they're operating on — the same way the website does automatically. The new version requires us to be on the current major versions of our platform (PHP 8.2, Symfony 6.4+, Sylius 2), which aligns with where we're already heading. There is no rewrite: the migration guide states no application code changes are needed. The decision it informs is when, not whether, to complete the platform upgrade — and it adds a small, low-risk dependency to that plan rather than a new project.

For engineering: v2.0.0 is a dependency and tooling upgrade, not a feature release. PHP floor moves to 8.2; Symfony to ^6.4 || ^7.4; Sylius to v2; symfony/service-contracts to ^3.0. Service config moved from XML to PHP because XmlFileLoader is deprecated in Symfony 7.4 — expect that pattern in other bundles too. Psalm has been swapped for PHPStan at level 9 with strict, Symfony, PHPUnit, deprecation, and prophecy extensions; PHPUnit 11 and Rector 2 (UP_TO_PHP_82) are in place. The public API (StaticChannelContext, StaticLocaleContext) is unchanged in both interface and behavior. New tests cover reset(), null-unsetting, DI service registration and tag priorities, and the bundle class — so the risky area for us (context leaking across queued jobs) now has explicit coverage. Upgrade is composer require setono/sylius-static-contexts-bundle:^2.0 once the platform requirements are met; otherwise pin to 1.x and track it as debt. Validate the Symfony ^7.4 constraint against your actual installed version before bumping, and confirm reset() is invoked in every long-running consumer.