Sylius 1 11 Shim Bundle Laravel Package

Getting Started

This is a transitional compatibility bundle: it re-introduces behaviour that existed in Sylius 1.11 but was removed/changed in 1.12+. Treat it as a bridge during an upgrade, not as a permanent dependency.

Minimal steps:

1. Require it (runtime, not dev-only, because it registers services/compiler passes at boot):

   composer require sylius-labs/sylius-1-11-shim-bundle
   

   Confirm your project is actually on Sylius ≥ 1.12 first — the bundle is pointless (and may conflict) on 1.11.

2. Register the bundle in config/bundles.php. Order matters for bundle-loading bundles — put it after the Sylius bundles so its service overrides win:

   SyliusLabs\Sylius111ShimBundle\Sylius111ShimBundle::class => ['all' => true],
   

3. Clear the cache (bin/console cache:clear) and boot the app. If anything throws ServiceNotFoundException/ClassNotFoundError that used to work on 1.11, that's exactly the symptom the shim is meant to fix.

Where to look first:

• The bundle's src/ — specifically DependencyInjection/, Resources/config/services.*, and any CompilerPass/. This tells you exactly which services, parameters, or templates it re-registers. Do this before relying on it; it's a one-release, zero-star package, so the source is the spec.
• Its composer.json for the Sylius/Symfony version constraints.
• The repo README and any upgrade notes in the Sylius 1.11→1.12 UPGRADE guide, to map each shim feature back to the change that removed it.

First use case: you upgraded a project (or a third-party plugin) from Sylius 1.11 to 1.12, and a service, model helper, or template block your code relied on no longer exists. Install the shim, verify the missing symbol resolves and your existing Behat/PHPUnit suite goes green again, then start removing the legacy calls.

Implementation Patterns

• Bridge-then-burn. Install the shim on a dedicated upgrade branch, get the full test suite green on 1.12 with it enabled, then progressively remove the legacy API calls it's papering over. Remove the bundle from config/bundles.php and composer.json before merging long-term. Track each removal as a checklist item so the debt is visible.
• Use it to discover what changed. Because it restores 1.11 surface area, diffing the shim's service definitions against current Sylius core is a cheap way to enumerate the BC breaks affecting your code. Each restored service is a refactor target.
• Pair it with deprecation logging. Enable logging for Sylius/Symfony deprecations in config/packages/dev/monolog.yaml and run your suite; anything hitting restored services shows up as a deprecation you can chase down.
• Guard registration per environment. Register the bundle only where it's needed during the migration (e.g. ['dev', 'test'] in config/bundles.php) so production runs on clean 1.12 behaviour. This also flushes out hidden dependencies on the shimmed code.
• Validate plugins against it. A common workflow when maintaining a Sylius plugin: run your existing 1.11-oriented test matrix against 1.12 with the shim enabled to confirm the plugin can run, then update the plugin to 1.12 APIs and drop the shim.
• Decorate, don't edit. If a shimmed service needs a tweak for your app, use a Symfony service decorator or a compiler pass in your own bundle rather than editing vendor code.

Gotchas and Tips

• Version scope. The bundle targets Sylius 1.12+. Pinning sylius/sylius too loosely risks pulling 1.13/2.x where core may have re-introduced or re-removed the same APIs, causing duplicate service definitions or signature conflicts.
• Bundle order. Register after Sylius\Bundle\CoreBundle and friends. If a Sylius bundle loads later, its service definitions can overwrite the shim's.
• Doctrine collisions. If the shim re-declares entity/model mappings, watch for The class ... was not found or duplicate-mapping errors after cache:clear. Run bin/console doctrine:schema:validate post-install.
• Service overrides can be silently shadowed by your app's config/services.yaml or config/packages/*.yaml. Use bin/console debug:container <service> to see which definition actually wins.
• Cache is the usual culprit. After toggling the bundle, always cache:clear and, ideally, cache:warmup. Stale container XML masks whether the shim did anything.
• Zero stars, single 2022 release. No security backporting, no active maintenance. Audit the whole source (it's tiny), and if you need it long-term, fork it into your own namespace rather than depending on upstream.
• Don't ship it to production as a "fix". If production is silently relying on shimmed behaviour, the upgrade isn't finished — treat the shim as a failing test, not a solution.
• Debugging tools: debug:event-dispatcher if it re-wires listeners; debug:twig if it restores template functions/blocks; debug:router for any restored routes. For legacy template event blocks, confirm the block is actually dispatched (bin/console debug:event-dispatcher sylius.ui...) before blaming the shim.
• Extension points to prefer over the shim: Symfony service decoration, sylius.resource overrides, and form/event subscribers are all more durable than depending on a re-introduced 1.11 API.