Sylius Rector Laravel Package

Product Decisions This Supports

• Platform upgrade planning: Helps decide when to schedule Sylius upgrades, how much engineering capacity to reserve, and which platform versions remain supportable. As of v3.9.0, rule sets are bound to the installed Sylius version through Composer, so the tool's behavior tracks the platform version the team is actually on — a small but real improvement for upgrade forecasting.
• Build vs. buy for migration tooling: Supports using vendor-maintained Rector rules instead of building and maintaining bespoke upgrade scripts. The trade-off is lower license cost but requires engineering validation and code review.
• Roadmap de-risking: Makes upgrades a planned maintenance workstream rather than an emergency. This is especially relevant before launching new commerce features, changing hosting, or extending plugin/theme dependencies. New rules for Doctrine indexing on extended classes and for the LiveOnePageCheckout plugin extend this to plugin and data-model-level migrations, not just API renames.
• Use cases: Major/minor Sylius upgrades, plugin compatibility checks (including common plugins now covered by dedicated rules), CI enforcement against deprecated APIs, cleanup of legacy customizations, and developer onboarding to current Sylius conventions.
• Investment framing: This is not a customer-facing feature. It is upgrade infrastructure that protects security patching, reduces platform debt, and lowers total cost of ownership for a Sylius-based commerce product.
• Replatform signal: If the team cannot justify ongoing upgrade automation for Sylius, that is a useful input into a broader build-vs-replatform or platform-strategy discussion.

When to Consider This Package

Consider it when:

• The product runs on Sylius, not a generic Laravel or Symfony application. Despite being a PHP package, it is Sylius-specific.
• There is a planned Sylius upgrade and the team expects custom code, templates, plugins, or integrations to require mechanical refactoring.
• Engineering already uses Rector or is willing to adopt it in CI, with reviewable diffs and a test suite to validate changes.
• The target Sylius version has rule coverage in this package, and the team can verify coverage against its own customizations.
• The team can absorb a one-time configuration change: v3.9.0 replaces the previous set provider with Composer version-bound rule configurations. Existing rector.php set references may need to be rewritten, and rule behavior now depends on the installed Sylius version — plan a short spike to re-baseline CI before an upgrade branch depends on it.
• The organization values repeatable, vendor-aligned upgrade tooling over one-off migration scripts.

Look elsewhere or proceed cautiously when:

• The application is Laravel-based, non-Sylius, or has no Sylius upgrade on the roadmap.
• The package does not cover the target version or the team's most expensive customizations.
• The team cannot review automated code changes or lacks tests to catch regressions.
• The upgrade problem is primarily data migration, business-process change, or third-party integration work rather than PHP code refactoring.
• Low adoption is a concern: the package has very few stars and no listed dependents. The steady release cadence (v3.8.1 → v3.9.0, with new rules each cycle) is a positive maintenance signal, but rule coverage and long-term stewardship should still be validated before relying on it. Alternatives include manual upgrades, paid Sylius partners, community Rector rules, or replatforming.

How to Pitch It (Stakeholders)

For executives: This is an open-source upgrade automation package for Sylius commerce platforms. It can reduce the cost and risk of staying current on the platform, which protects security patching, compliance, and feature velocity. There is no license fee, but there is an engineering validation cost. Treat it as maintenance infrastructure, not a revenue feature.

For engineering: It provides Rector rules that automate mechanical Sylius upgrade changes, making migrations more repeatable and CI-friendly. The latest release moves rule sets to Composer version-bound configurations, which should make rule selection more deterministic but requires a config migration; it also adds coverage for Doctrine index changes on extended classes and the LiveOnePageCheckout plugin. It does not replace tests, manual review, or judgment on custom business logic. Start with a pilot on one upgrade branch, budget an hour or two for the configuration change, and measure hours saved and defects caught.

For product managers: Use it to frame upgrades as planned platform maintenance rather than emergency work. It helps negotiate scope and capacity for modernization, and the growing plugin/Doctrine rule coverage broadens the share of upgrade work that can be automated rather than hand-scoped. The caveats are maturity and a configuration change in this release: the package is niche and lightly adopted, so validate rule coverage for your Sylius version and confirm the new version-bound configuration works in your pipeline before committing it to the upgrade plan.