Rector Laravel Package

Product Decisions This Supports

• Upgrade roadmap and cost estimation. The package exists to automate Ibexa DXP version upgrades (e.g. 4.6 → 5.0). For a PM, its primary value is as a sizing instrument: run it against a representative bundle and the resulting diff volume tells you how much of the migration is mechanical versus genuinely manual. That converts "we think the upgrade is big" into an estimated engineering effort you can put on a roadmap.
• Build vs. buy / build vs. automate. The alternative is funding an internal codemod project or paying for hand-refactoring. This is a vendor-maintained, versioned rule set installed as a dev dependency — a "buy" (or rather, "leverage the subscription we already pay for") decision rather than a build decision, freeing engineering capacity for the semantic work only humans can do.
• Defer / stay / jump decisions on platform lifecycle. Because rule sets are versioned per target (IbexaSetList::IBEXA_50), the tool supports a concrete comparison: cost of staying on 4.6 LTS versus funding the jump to 5.0. It makes the "when do we migrate?" question answerable with data rather than vibes.
• Portfolio-level platform decisions. If the organization is weighing "renew Ibexa DXP vs. re-platform," the migration cost is a direct input. A cheap, partially automated upgrade path materially improves the case for staying.
• Sequencing in hybrid estates. In a realistic setup where Ibexa DXP supplies content/headless APIs and Laravel supplies the application layer, this tool cleanly isolates backend upgrade work from app-layer work — useful for parallelizing teams and avoiding a single monolithic migration epic.
• Release planning and staffing mix. It lets you split a migration into three lanes with different owners: automated rewrite (tooling), diff review (senior engineers), and architectural/config/data migration (specialists). That's a staffing plan, not just a technical plan.
• Risk register inputs. Documenting what the tool doesn't cover — removed extension points, database and configuration migrations, architectural breaks — defines the manual workstream and justifies the test-coverage investment.
• Vendor dependency / budget line. Adoption ties into the Ibexa subscription (the Business Use License branch), so it belongs in vendor-management and renewal discussions rather than as a new standalone tooling purchase.

When to Consider This Package

Consider it when:

• You operate Ibexa DXP (or inherited eZ Platform code) somewhere in the estate, and there is a real, scheduled, funded upgrade on the roadmap. No scheduled upgrade, no business case.
• You hold an active Ibexa DXP subscription that satisfies the Business Use License — or legal has explicitly cleared GPL-2.0 use for your distribution model. Confirm this before the spike, not after.
• The Ibexa-side codebase contains meaningful custom code (custom bundles, field types, templates, REST extensions). Vanilla installs get little value; the savings scale with custom surface area.
• You have reasonable test coverage on that code, or you are willing to fund coverage / supervised review. This is the real gating criterion — the tool rewrites code, and someone must judge semantic equivalence.
• Your engineers already work with Rector or similar static-analysis tooling. The workflow (config file, --dry-run, reviewed diff) is then familiar and cheap to adopt.
• You need the upgrade to be repeatable and auditable across multiple projects or environments — a rule set beats tribal knowledge.

Look elsewhere when:

• The codebase is Laravel-only. This is not a Laravel package: no service provider, no runtime footprint, no integration points, zero relevance.
• Ibexa DXP is only a speculative future integration. Adopting the migration tool before adopting the platform is backwards.
• The upgrade effort is dominated by configuration, database schema, content model, or removed extension points. Rules encode known deprecations; they will not carry the migration.
• You have no test coverage and no review capacity. Automated rewrites without a reviewer are a net risk, not a saving.
• Licensing cannot be cleared — no subscription and GPL-2.0 incompatible with your redistribution or procurement policy.
• You need a path not covered by a published rule set, such as skipping several majors in one jump.
• You expect community support. With 1 star and 0 dependents there is effectively no third-party corpus; support flows through the vendor relationship.

How to Pitch It (Stakeholders)

For executives (one paragraph): We already pay for Ibexa DXP. This is a small, vendor-maintained developer tool that automates a portion of the code changes required when we upgrade DXP versions. It installs as a development-only dependency — no runtime footprint, no infrastructure, no deploy changes, no production risk. Its value is measured in engineering hours removed from an upgrade we have already scheduled: it converts hand-refactoring into generated diffs that engineers review. Two caveats to clear up front: it is dual-licensed under GPL-2.0 or the Ibexa Business Use License, so legal must confirm our subscription covers it; and its public adoption is negligible, so support comes from our vendor relationship rather than the community.

For engineering leads: One composer require --dev ibexa/rector:^5.0, one rector.php declaring paths plus a single versioned set, then php ./bin/rector process <dir>. The set list is keyed to the target DXP major, so the tool is scoped to one version hop and one directory at a time — favourable for phased delivery. Treat output as a PR from a junior engineer: run --dry-run, review every diff, and rely on test coverage to catch behavioural drift. Version-lockstep matters — package major tracks DXP major, so a ^5.0 install against a 4.6 codebase is a misconfiguration, not a downgrade path.

The ask: Approve a timeboxed spike — one engineer, one sprint, one representative custom bundle, dry-run against the relevant rule set. Success criterion is a measurable estimate: lines of mechanical change automated versus hours of manual refactoring avoided, plus a documented list of what the rules missed. That output decides full rollout, and it doubles as the sizing input for the upgrade business case.