Rector Config Laravel Package

Getting Started

composer require --dev stickee/rector-config

A Rector config package normally ships a shared rector.php (or a base ruleset class) so teams don't copy-paste rule definitions between projects. Expect two integration paths:

1. Import the base config from your project root rector.php:

   <?php
   use Rector\Config\RectorConfig;
   
   return RectorConfig::configure()
       ->withPaths([__DIR__ . '/app', __DIR__ . '/src'])
       ->withPreparedSets(
           // if the package exposes a set constant
           // \Stickee\Rector\Set\StickeeSetList::STICKEE_STRICT
       );
   

   Or, if it ships a plain config file, withSets([__DIR__ . '/vendor/stickee/rector-config/rector.php']).

2. Check the README first — with 0 stars and 0 dependents this is a very small (likely internal-first) package; the composer autoload/extra section and the repo's rector.php will tell you more than any docs will.

Your first useful use case: run it in dry-run on a single directory before touching a whole codebase.

vendor/bin/rector process app/ --dry-run

Read the diff, confirm the rules match your team's style conventions, then remove --dry-run. Because this is effectively a one-maintainer config wrapper, treat the first run as an audit of the ruleset, not just your code.

Implementation Patterns

• Shared team baseline. The core value is one canonical Rector rule set across all Stickee-flavoured projects. Point every service at the same package version so upgrade PRs stay in lockstep. Pin an exact tag ("stickee/rector-config": "1.2.3") rather than ^ if you want reproducible refactors across repos.
• CI as a gate, not an enforcer. Run Rector in dry-run inside CI on changed files only. Rector's full-repo runs are slow; scope with --only/withPaths() to the diff. Fail the build on a non-empty dry-run if you want to force cleanup, or just report it.
• Local pre-commit loop. A common workflow: composer rector:check (dry-run) locally, apply with vendor/bin/rector process <path>, review the diff, commit. Keep the apply step manual — auto-applying Rector in a hook creates noisy commits.
• Extend rather than edit. Consume the package's prepared set/config, then layer project-specific rules on top in your own rector.php. Don't edit files under vendor/. If you need a rule the package doesn't ship, add it alongside; upstream it later.
• Version-gated upgrades. Rector rules change between Rector majors. When you bump Rector, bump this package in the same PR and re-run dry-run — treat it like any codegen tool, where the tool version and the "config" version must move together.
• Pair with a PHP version. Set ->withPhpSets(php82: true) (or whatever your runtime is) in addition to the package's set. The package config likely assumes a PHP baseline; verify it matches yours.

Gotchas and Tips

• Nearly no adoption signal. Zero stars, zero dependents, single last release (2025-02-05). That doesn't mean it's bad — internal Stickee tooling is often private-first — but it does mean: pin it, vendor it, and don't expect community answers to problems. Read the source; it's likely 1–2 files.
• Rector config is PHP, not data. Small config packages are easy to break subtly — path assumptions, autoload order, or a withSets() that silently no-ops if the class name changed between Rector versions. If nothing changes after a run, confirm the set is actually loaded (vendor/bin/rector list / verbose output).
• --dry-run is non-negotiable on first use. Rector rules can be opinionated (e.g. aggressive type declarations, removing docblocks). The package encodes someone's conventions. Diff against a small module before rolling across the monorepo, and check whether the ruleset assumes strict types or specific PHPStan/PHPCS alignment.
• Autoload and caching. Rector caches aggressively (var/cache/rector). After editing rector.php or bumping the package, clear the cache (vendor/bin/rector process --clear-cache) or you'll debug phantom behaviour.
• No config scaffolding guaranteed. Some packages ship a rector.dist.php you're meant to copy; others export a class. Check composer.json autoload and the repo tree — the README may be thin. If there's a src/ with a Set/ namespace, you're meant to reference a constant; if it's just rector.php, you're meant to withSets() the file path.
• Debugging a wrong refactor. Isolate with --only=<Rule::class> from the dry-run output (--debug prints applied rules). If a rule from this package misfires, the escape hatch is to skip it by name in your own config rather than forking the vendor package.
• Extension point: most such packages are just a RectorConfig builder. If your needs diverge, copy its two or three rules into a local rector.php and drop the dependency — you lose nothing but the update stream, and you gain full control (worth it when adoption is this low).
• License is MIT — safe to vendor/copy, no attribution friction. That said, if it's abandoned, vendoring the source into tools/ is a reasonable long-term move.

Verdict for day-to-day use: adopt only if you're already in the Stickee/PHP-Rector ecosystem and want a shared baseline; verify by reading the (short) source before relying on it. For everyone else, a hand-rolled rector.php with the same prepared sets gives the same benefit with none of the single-maintainer risk.