Rector Laravel Package

Technical Evaluation

Architecture fit

• This is not a Laravel package and should not be evaluated as one. ibexa/rector is a first-party Ibexa DXP developer tooling package: a curated bundle of Rector rules that mechanically rewrite Ibexa DXP application code between major versions. There is no service provider, no runtime footprint, no facade, and no integration surface with a Laravel application.
• Fit is therefore binary. It is high value if we operate Ibexa DXP (or inherited eZ Platform code) anywhere in the estate, and zero value otherwise. The realistic enterprise scenario is a hybrid estate where Ibexa DXP serves content/headless APIs and Laravel serves the application layer — in that case this package addresses the Ibexa-side upgrade cost and leaves the Laravel side untouched.
• The architecture is deliberately incremental: rules are grouped into versioned sets (e.g. IbexaSetList::IBEXA_50) and applied to declared paths. That means we can scope a refactor to one target version and one directory rather than a repo-wide rewrite — a favourable property for phased delivery and for keeping diffs reviewable.

Integration feasibility

• Setup cost is genuinely low: composer require --dev ibexa/rector:^5.0, a single rector.php at project root declaring paths and a rule set, then php ./bin/rector process <dir>. No infrastructure, secrets, or deployment changes.
• The real cost is not installation — it is review capacity. Every automated diff needs an owner who can judge semantic equivalence. A TPM should budget for review hours and test hardening, not for setup.
• Prerequisites to confirm: the host project must already be a working Ibexa DXP install; Rector 2.x implies a PHP 8.1+ baseline; the 5.0 line aligns to Symfony 7.4 LTS; the package major tracks the DXP major, so ^5.0 against a 4.6 codebase is a misconfiguration, not a supported downgrade path.

Technical risk

• Licensing is the headline risk. The package is dual-licensed under GPL-2.0 or the Ibexa Business Use License, and the BUL branch requires a valid Ibexa DXP subscription. Despite appearing on Packagist, this is not a clean single-OSI license. Legal review is a gating item, especially if any artifact or generated code is redistributed, or if we lack an active subscription.
• Transformation risk outweighs dependency risk. Being dev-only, blast radius on production is nil; the exposure is a rule that rewrites working code into subtly differently-behaving code. Adequate test coverage is the mitigating control, and where coverage is thin, --dry-run plus manual diff review must be mandatory rather than optional.
• Coverage risk. Rules encode known deprecations only. They will not catch removed extension points, architectural breaks, or database/schema and configuration migrations. Treat this as one lane of a migration, never the migration itself.
• Weak adoption signal. One star and zero dependents means effectively no community corpus — no third-party writeups, no Stack Overflow answers. Mitigant: it is vendor-maintained with issues tracked in Ibexa's Jira, so support flows through the commercial relationship rather than the community.
• Release noise. A large share of releases read "No significant changes," suggesting the changelog is inherited from a monorepo pipeline. Do not infer stability from release count; pin explicitly and upgrade deliberately.

Key questions

1. Do we actually run Ibexa DXP today, and on which version — or is this speculative for a future integration?
2. Do we hold an active Ibexa DXP subscription satisfying the BUL, or would we be relying on GPL-2.0? Has legal signed off?
3. What is current test coverage on the Ibexa-side code? Below a reasonable threshold this becomes a supervised-refactor project, not an automated one.
4. Which specific upgrade are we funding (4.6 → 5.0, or a 5.x minor)? The business case only holds against a real, scheduled upgrade with a delivery date.
5. Who owns diff review and merge for the automated changes, and how many engineer-days are they allocated?

Integration Approach

Stack fit

• Native PHP/Composer tooling that sits alongside the Ibexa application repository. It requires an installed Ibexa DXP project, Composer, and PHP 8.1+; it does not touch the Laravel application, its container, or its CI pipeline unless we deliberately add a step there.
• Because it is a --dev dependency, it never ships to production images. That keeps the security and supply-chain surface effectively confined to developer machines and CI runners.

Migration path

1. Qualify the target. Instantiate rector.php in the Ibexa project only, with withPaths() scoped to our own src and tests — explicitly excluding vendor and any first-party bundles we do not own.
2. Baseline before changing anything. Run --dry-run and record the diff statistics (files touched, hunks per rule set). That baseline is the TPM's burndown metric and the estimate correction for the upgrade project.
3. Work on a dedicated upgrade branch. Never on main. Commit per rule set, not per file, so a failing test can be bisected to a specific transformation.
4. Sequence sets in version order. Apply the lowest applicable set first, get green, then move up. Mixing sets obscures which rule caused a regression.
5. Follow with the manual lane. After Rector stabilises, handle schema/config migrations, removed extension points, and behavioural changes that no codemod covers.
6. Gate the endpoint. Full test suite plus smoke tests on a staging Ibexa instance before merge.

Compatibility

• Pin the package major to the DXP major being targeted; verify the PHP and Symfony constraints of the chosen package line against the host project before installing to avoid a Composer resolution dead-end.
• Rector rules are version-sensitive in both directions: rules published for a target version assume the pre-upgrade code shape. Applying a 5.0 set to already-upgraded code is at best a no-op and at worst a mis-rewrite. Confirm the current DXP version explicitly.

Sequencing

• Best positioned as the first workstream of a scheduled DXP upgrade, executed before manual remediation, so human effort is spent only on what the tool cannot fix. It should not be adopted opportunistically ahead of a committed upgrade — the value is entirely realised at upgrade time.

Operational Impact

Maintenance

• Ongoing maintenance burden is low: the vendor maintains the rules in lockstep with DXP releases, and we consume them as a pinned dev dependency. Our obligations are version pinning, periodic deliberate upgrades, and watching the changelog for entries that actually carry rule changes (many do not).
• One internal owner should be named for the rector.php config, since path scoping errors are the most common self-inflicted problem.

Support

• Support routes through the Ibexa commercial relationship and their Jira, not through open-source channels. Without a subscription, we are effectively self-supporting on an unfamiliar ruleset — which argues for not adopting it at all without the BUL in place.
• Retain the ability to disable any individual rule or set; a misbehaving rule must be bypassable without forking the package.

Scaling

• Technically trivial: CPU-bound static analysis in CI, no runtime, no infrastructure, no capacity planning. Cost scales with lines of code and, far more importantly, with review throughput — human diff review is the true bottleneck, and it scales linearly with transformed surface area.
• For a large codebase, parallelise by directory/bundle and stagger reviews rather than attempting a single mega-diff.

Failure modes

• Silent under-coverage: deprecations with no corresponding rule pass through untouched, giving false confidence that "Rector was run."
• Semantic drift: a rule produces compiling but behaviourally different code; only tests catch this.
• Scope creep in paths: rewriting vendor or generated code, producing unreviewable noise.
• Version mismatch: running a set against the wrong DXP major.
• License non-compliance: shipping or redistributing under the BUL without a subscription.
• Changelog complacency: treating "no significant changes" releases as evidence of maturity rather than pipeline noise.

Ramp-up

• Engineer ramp-up is short — a competent PHP developer can configure and run Rector in an afternoon; the config surface is a handful of documented calls.
• TPM ramp-up is where the effort sits: license clearance, review-ownership assignment, test-coverage assessment, and defining the success metrics. Useful metrics to instrument from day one: files/hunks transformed per rule set, post-migration test pass rate, defects traced back to automated rewrites, and engineer-hours saved against the manual-upgrade estimate.
• Bottom line for a TPM: sponsor this only as a component of a funded, scheduled Ibexa DXP upgrade, with legal sign-off on the license and a named review owner in place before the first non-dry run.