- What is rector/rector-generator used for?
- Rector Generator scaffolds a custom Rector rule from templates: a PHP class implementing Rector's rule contract plus a fixture and test stub. It only helps author refactoring or upgrade automation; it is a development-time code-generation tool, not a runtime dependency. Use it only if Rector is already part of your upgrade pipeline.
- Is rector/rector-generator still maintained?
- No. It lives under the deprecated-packages namespace with zero stars and zero dependents, and Composer flags it as abandoned. There is effectively no upstream maintenance, so anything you adopt becomes your code to patch. Do not build new work on it.
- Should rector/rector-generator be in require or require-dev?
- require-dev only, alongside rector/rector, Pint, and PHPStan or Larastan. It generates source files during authoring and has no role at runtime. Installing it as a production dependency would be wrong.
- Does rector/rector-generator work with current Rector versions?
- Its generated stubs are coupled to a specific Rector API surface, including AbstractRector signatures, getRuleDefinition() return shapes, and RuleDefinition constructor arity. Those have moved repeatedly across Rector majors, so the generator can emit classes that no longer compile. Assume no PHP 8.4 or 8.5 readiness and no Laravel-specific fixes.
- Is there a built-in Rector command that replaces this package?
- Yes. Rector core bundles its own rule-generation command, though the exact command name varies by version. This package duplicates a maintained feature with an unmaintained one. Use the bundled generator that matches your pinned Rector major.
- Will installing rector/rector-generator block Composer updates or Laravel upgrades?
- It can. A pinned abandoned dev dependency can entangle the lockfile and block composer update of Rector, PHPUnit, or PHPStan, which cascades into blocked framework upgrades. Run composer why-not rector/rector <version> before adding it to see whether its constraints block the Rector version you want. The safest move is to avoid the dependency entirely.
- How do I generate a custom Rector rule for a Laravel project today?
- Pin rector/rector to a supported major and use its bundled rule-generation command to scaffold the class and test stub. If you want a scaffold you control, copy the generated class shape into an internal tools/ or stubs/ directory once and own those roughly 30 lines. Keep Rector running in dry-run mode in CI on pull requests.
- Do I need custom Rector rules, or are community Laravel rule sets enough?
- Check community rule sets first, because they often cover common Laravel and PHP migrations without custom code. If you still need custom rules, hand-author one or two to prove the value for your codebase before adding any scaffolding tooling. Doing that order avoids buying ceremony instead of migrations.
- How do I test a generated Rector rule?
- A generated rule normally comes with a fixture and a test stub; add the fixture input and expected output, then run the test through PHPUnit or your normal test suite. Also run Rector in dry-run mode against a sample project to confirm the rule behaves as intended. Because stubs are version-coupled, verify the generated class compiles against your pinned Rector major.
- How should I remove rector/rector-generator from an existing project?
- Remove it in the same pull request as the Rector upgrade, never across separate releases. Replace any scaffold you still need with an internal stub or the bundled Rector generator, then run composer update and the full test suite. Leaving the abandoned package pinned between incompatible Rector versions will strand your lockfile.