Shopware Rector Laravel Package

Technical Evaluation

Framing correction (unchanged). This is not a Laravel package. frosh/shopware-rector targets Shopware (6.x, with migration-oriented rules for legacy/plugin code) and depends on rector/rector, nikic/php-parser, and Shopware core classes. Its applicability is gated entirely on whether the estate runs Shopware; for a Laravel-only portfolio the evaluation stops here.

Architecture fit (unchanged). Developer-time static-analysis tool, not a runtime dependency. Correct integration surface is require-dev plus a committed rector.php per Shopware repo, run locally and in CI, alongside PHPStan / PHP-CS-Fixer. No application-layer coupling, no service provider, no runtime overhead. 0.6.0 strengthens this fit: the package now runs PHPStan against itself (PR #67), so it participates in the same quality-tooling substrate we already operate rather than being an opaque binary.

Integration feasibility. Still mechanically trivial: one Composer dependency, one config, one CI step. Two changes affect feasibility:

• PHP floor moved 8.1 → 8.2 (PR #69). This is a breaking change landing in a 0.x minor, which is permitted pre-1.0 but means we must treat every minor as potentially breaking. In practice this is a non-event for Shopware 6.6/6.7 estates (already PHP 8.2+), but it will block any legacy plugin still pinned to 8.1 — inventory those first.
• The rule scaffold script and devenv setup were removed (PR #68). The custom-rule authoring path is now less turnkey. Since internal custom rules for house patterns were already the deferred, high-hidden-cost phase, this does not change the plan, but it raises the estimated cost of that phase and should be re-scoped before committing to it.

Technical risk.

• Maturity signal — mixed.* Still low stars/dependents and a single named maintainer (@shyim). However, 0.6.0 is a genuine maintenance signal: a compatibility fix restoring Rector 2.6.2 support, dependency modernization, and a new deprecation rule. The project is not abandoned; it is thinly staffed. Still "adopt with guardrails," not implicit trust.
• Version coupling — the dominant risk, now with better news. "Restore Rector 2.6.2 compatibility" (PR #67) confirms the suspected failure mode (Rector API drift silently breaking rules) has already occurred once upstream. Positive: it was fixed and PHPStan was added to catch recurrence. Negative: it confirms the coupling is real and reactive, not anticipatory. Pinning the rector/rector + frosh/shopware-rector + shopware/core trio remains mandatory.
• Transformation risk (unchanged). Rector rewrites source; false positives compile and misbehave. The new CartBehavior recalculation rule (PR #64) edits storefront/checkout recalculation logic — a class of change where a plausible-looking rewrite can alter cart totals. Elevated review scrutiny required for this rule specifically.
• Provenance of new rules. PR #64 is credited to @shyim with @Copilot. AI-assisted rule authorship is not disqualifying, but it shifts the burden of proof onto fixture coverage. Ask specifically what test fixtures accompany the CartBehavior rule and whether it was validated against real 6.6/6.7 plugins.
• Pre-1.0 semantics. 0.6.0 demonstrates the project will ship breaking changes in minors (PHP floor) and remove developer affordances without a deprecation cycle (scaffold script). Treat upgrades as deliberate, tested events rather than routine composer update.
• Data anomaly (retained). Release metadata dates should still be reconciled against Packagist before planning assumptions depend on them. The composite-vs-opportunity score gap remains a low-adoption signal that 0.6.0 does not materially close.

Key questions.

1. Which Shopware versions and migration edges are covered (5→6? 6.x deprecation sweeps? 6.5→6.6/6.7?), and which Rector major/minor is now the pinned target — is 2.6.2 a floor or a ceiling?
2. Is the PHP 8.2 floor driven by the code or by dev dependencies, and is there a supported path for a repo still on 8.1?
3. What fixture/test coverage backs the new CartBehavior recalculation rule, and was it validated against real plugins rather than only fixtures?
4. Does the removal of the rule scaffold mean custom rules are no longer a supported workflow, or merely that scaffolding moved elsewhere?
5. Coverage of plugin vs. app vs. theme structures — PHP only, or does it touch services.xml, DAL definitions, storefront JS?
6. Who is the named maintainer, what is the release cadence (0.5.11 → 0.6.0 interval), and is there a commercial support path via Frosh?
7. Does the package's own PHPStan setup compose with our baseline and PHP-CS-Fixer ordering in CI?

Integration Approach

Stack fit. Only viable inside Shopware 6 repositories (platform, plugins, or a plugin monorepo). PHP 8.2+ is now required, which aligns with Shopware 6.6/6.7 and simplifies the story for modern estates; it hard-blocks older plugins until they are uplifted. Keep it out of Laravel/Symfony repos entirely.

Migration path.

1. Inventory Shopware versions and PHP versions across all plugins/extensions; the 8.2 floor now gates wave selection as much as Shopware version does.
2. Pilot on one low-risk, well-tested plugin in a dedicated branch.
3. Establish a Rector baseline: generate once, commit, so existing violations are frozen and only new ones fail CI.
4. Validate the pinned trio (rector/rector, frosh/shopware-rector 0.6.x, shopware/core) in a throwaway branch before portfolio rollout — 0.6.0 exists precisely because that trio drifted.
5. Start with the narrowest applicable rule set; expand set-by-set with per-set diff review. Treat the CartBehavior rule as its own review unit with functional cart-total tests.
6. Apply the full migration set plugin by plugin, each behind a PR with tests.

Compatibility. Pin exact versions (not ranges) for the trio and lock them in CI. Do not float frosh/shopware-rector across minors — 0.6.0 shows both a PHP floor bump and a developer-tooling removal in a minor. Per-repo rector.php initially, consolidated once stable. Maintain a local skip list; re-verify it after every bump, since rule behavior can change between 0.5.x and 0.6.x.

Sequencing. Adjust the prior plan: tooling pilot (1 sprint) → baseline + CI dry-run gate (1 sprint) → first migration wave (per-plugin) → then reassess custom-rule authoring. That last phase is now more expensive and less supported than previously assumed (scaffold removed), so it should be re-estimated rather than carried forward at the original cost. Budget the PHP 8.2 uplift of any straggler plugins as a prerequisite task, not a parallel one.

Operational Impact

Maintenance. Community-maintained, no SLA, single maintainer — unchanged. 0.6.0 is evidence of active maintenance (compat fix, new rule, dependency refresh), which is reassuring but also confirms the maintainer is the sole bus factor. Assign a named internal owner and a pre-upgrade-cycle release review. MIT licensing keeps forking viable; the ~1 week vendor-and-patch contingency still stands, and is now slightly more attractive given demonstrated willingness to break in minors.

Support. GitHub issues only; unknown response times. The Frosh agency relationship remains a de facto, non-contractual escalation path. No change.

Scaling. Unchanged: CPU-bound, parallel by path, shard by plugin in CI. Minutes on a large plugin monorepo — fine as a pre-merge or nightly gate, too slow for pre-commit. The package's own added PHPStan step does not affect our runtime cost, but it is a mild positive signal for defect detection. Operational cost still scales linearly with repo count.

Failure modes.

• Breaking change in a minor — now demonstrated (PHP 8.1 → 8.2), not hypothetical. Pin exactly; read changelogs before bumping.
• Silent skips — version-gated rules that quietly no-op, giving false confidence. Diff file counts and assert expected change volume. Re-check after the 0.6.x bump, since the Rector 2.6.2 fix implies prior silent breakage was possible.
• Semantically wrong rewrites — highest concern for the new CartBehavior recalculation rule, where a compiling rewrite can alter cart totals. Functional tests on cart math are the only real control.
• Loss of developer affordances — scaffold script removal means custom-rule work now starts from scratch. Plan accordingly.
• Formatting collisions with PHP-CS-Fixer; fix run order (Rector before the fixer) early and re-verify after the dependency modernization in 0.6.0.

Ramp-up. Largely unchanged: roughly half a day for a PHP developer comfortable with Rector to a first productive run, one to two days to a config with sensible skips. Two adjustments: (a) confirm the local environment is PHP 8.2+ before the pilot, or the first hour is lost to a constraint error; (b) raise the estimate for authoring house custom rules now that the scaffold is gone — call it days, not hours, for the first rule. The runbook (baseline policy, dry-run workflow, PR review checklist, skip-list governance, pinned trio) remains the deciding artifact, with an added section on upgrade discipline for a pre-1.0, single-maintainer dependency.