Weave Code
Rector Laravel Package
ibexa/rector
ibexa/rector provides Rector rules for automatically upgrading Ibexa DXP projects between versions. Install as a dev dependency (composer require --dev ibexa/rector:^5.0), configure rector.php with an IbexaSetList set such as IBEXA_50, then run Rector on your source and tests.
Ibexa DXP Rector is a set of Rector rules that automate upgrades between Ibexa DXP versions. Install it as a dev dependency, create a rector.php config pointing at your source and test directories, select the target rule set (e.g. IbexaSetList::IBEXA_50), and run Rector to apply migrations automatically.
- Prebuilt rule sets for each Ibexa DXP upgrade path
- Simple project-level
rector.phpconfiguration - Works on your
srcandtestsdirectories - Extensible—add your own rules following the contribution guide
- Part of the official Ibexa DXP package family
Frequently asked questions about Rector
- Is ibexa/rector a Laravel package, and can I use it in a Laravel app?
- No. ibexa/rector is a first-party Ibexa DXP developer tool, not a Laravel package: it ships no service provider, no config publishing, and no runtime integration. Its only role is running Rector rule sets that rewrite Ibexa DXP application code between major versions. It is useful to a Laravel team only if the estate also runs Ibexa DXP (or inherited eZ Platform) and you are funding an Ibexa-side upgrade.
- How do I install ibexa/rector?
- Install it as a dev dependency with composer require --dev ibexa/rector:^5.0, and make sure the version line matches the Ibexa DXP major you are upgrading to. You also need Rector itself available so the bin/rector entry point exists. No infrastructure, secrets, or deploy changes are required; the whole setup is a Composer dependency plus one config file.
- How do I configure rector.php with IbexaSetList?
- Create a rector.php at project root, declare the paths you want processed (typically src and tests), and add the target rule set via IbexaSetList::IBEXA_50->value inside RectorConfig::configure()->withSets(). Then run php ./bin/rector process on a specific directory. Scoping paths to one directory keeps the diff reviewable and lets you migrate incrementally rather than rewriting the whole repository at once.
- Which Ibexa DXP versions does ibexa/rector support?
- The package major tracks the Ibexa DXP major it targets, so the 5.0 line is for upgrading to Ibexa DXP 5.0. Installing ^5.0 against a 4.6 codebase is a misconfiguration, not a downgrade path. Pin the version explicitly and align it with the specific upgrade you have scheduled.
- What PHP and Symfony versions does ibexa/rector require?
- Rector 2.x sets a PHP 8.1+ baseline, and the 5.0 line aligns with Symfony 7.4. Confirm both against your Ibexa DXP target before installing, since the tool runs in the same environment as your application code. If your codebase is still on an older PHP version, resolve that first.
- What license does ibexa/rector use, and can I use it commercially?
- It is dual-licensed under GPL-2.0 or the Ibexa Business Use License. The BUL option requires a valid Ibexa DXP subscription, so teams without an active subscription are relying on GPL-2.0 and its copyleft terms. It is not cleanly OSI-single-licensed despite appearing on Packagist, so legal review is a gating item before adoption, particularly if any artifact is redistributed.
- Does ibexa/rector run in production or affect runtime behavior?
- No. It is a dev-only dependency with no runtime footprint, so it cannot affect production behavior directly. The real risk is a rule that rewrites compiling code into differently-behaving code, which surfaces in your test suite and diffs. That is a review problem rather than a deployment risk.
- How do I safely test ibexa/rector before applying changes?
- Start with Rector's dry-run mode and review every diff before applying it. Where test coverage on the Ibexa-side code is thin, treat the run as a supervised refactor with an owner who can judge semantic equivalence. Budget effort for review capacity, not for installation.
- What can ibexa/rector not do during an Ibexa DXP upgrade?
- The rules encode known deprecations and API changes; they will not catch architectural breaks, removed extension points, or database and config migrations. Treat it as one lane of a migration, not the migration itself. Pair it with your test suite, static analysis, and a manual plan for the parts rules cannot see.
- Is ibexa/rector actively maintained, and where do I report issues?
- It is Ibexa-maintained and issue-tracked in Ibexa's Jira, so support flows through your vendor relationship rather than a community. Community signal is weak, with roughly one star and zero dependents, so expect no Stack Overflow corpus or third-party writeups. Many releases are tagged no significant changes, so do not infer stability from release count; pin explicitly and upgrade deliberately.
Weaver
How can I help you explore Laravel packages today?