- What is rector/rector-prefixed and how is it different from rector/rector?
- rector/rector-prefixed is a distribution artifact that bundles the Rector automated refactoring engine together with all of its dependencies under isolated, prefixed namespaces. That prefixing lets you run Rector inside a project whose Composer dependency graph would otherwise collide with Rector's own vendor tree. The source was also downgraded to PHP 7.1 so it can execute in older environments. It is not a superset of Rector; it is a frozen snapshot of it, and modern rector/rector is itself shipped as a self-contained prefixed package, which is why this repository was deprecated.
- Is rector/rector-prefixed still maintained?
- No. The repository is archived and read-only, the last release was published in April 2021, and Composer surfaces the package as abandoned. There is no security patching, no upstream bug fixes, and no PHP 8.1+ compatibility work. Treat any adoption as pinning a frozen legacy artifact rather than depending on a maintained package.
- Can I use rector/rector-prefixed in a Laravel application?
- Yes, but only as a development or CI tool. Rector is a CLI that reads and rewrites PHP source files, so there is no service provider, facade, config publish step, or any other framework integration surface to wire into Laravel. It belongs in require-dev and should never appear in a production build target or runtime image.
- Which PHP versions does rector/rector-prefixed support?
- It targets PHP 7.1 and above by construction, because the source was downgraded so the prefixed build could run on older interpreters. It will not run reliably on PHP 8.1 and newer, which is the practical ceiling for most modern Laravel codebases. If your application or CI image is already on PHP 8.1+, this package is not a viable choice.
- How do I install rector/rector-prefixed?
- Install it with composer require --dev rector/rector-prefixed, then pin the exact locked version rather than using a caret constraint. Composer 2 will resolve the package but emit an abandoned-package warning, which you should document rather than suppress silently. For anything beyond a one-off run, execute it inside a container image so the PHP version is controlled and the toolchain cannot drift under you.
- Should rector/rector-prefixed be a require or require-dev dependency?
- Always require-dev. It never belongs in a production dependency list or a Laravel runtime image, since it rewrites source code at development time and has no runtime role. Keeping it in require-dev also guarantees a --no-dev production build cannot accidentally ship it. The production blast radius is near zero as long as that boundary is respected.
- Will the prefixed namespaces conflict with my Laravel app's Composer packages?
- The whole point of the prefixed distribution is to avoid that: Rector's internals are namespaced under a unique prefix so they cannot collide with your application's vendor tree. In practice this is safe, but prefixed internals can still shadow classes in unusual setups, so validate it in the specific repository before relying on it in CI. If you hit odd class resolution errors, that is the first thing to investigate.
- How do I migrate from rector/rector-prefixed to the current rector/rector?
- Treat it as a standalone modernization workstream rather than a drop-in swap. Configuration moves to rector.php, rule class names and set lists have changed, and the PHP constraint shifts upward, so expect to rewrite your config and re-validate every rule you rely on. A practical approach is to run the old pinned snapshot and the modern rector/rector in parallel on the same branch and diff the results before cutting over. Afterwards, remove the dependency and record a policy note that archived dev tooling needs an exception.
- Can I run rector/rector-prefixed in a CI pipeline?
- You can, but isolate it in a container image with a fixed PHP version and pin the exact Composer version. Do not build new automation on top of it, because a CI job that silently depends on an unmaintained artifact will break the moment your toolchain moves. Use it for bounded, one-off refactoring runs and plan the exit before you wire it into a pipeline.
- What are the alternatives to rector/rector-prefixed?
- The primary alternative is the current rector/rector package, which is itself distributed as a self-contained, prefixed tooling package and is actively maintained. The standalone Rector PHAR is another option when you want zero impact on your project's Composer graph. If you genuinely must stay on an old PHP version, the only defensible route is forking and patching a pinned build with a named internal owner and an explicit removal timeline.