Extension Installer Laravel Package

Product Decisions This Supports

• Tooling standardization across repos. Decides whether Rector extension configs (Laravel, Symfony, Doctrine, PHPUnit sets, etc.) are auto-registered via Composer or hand-maintained in each rector.php. This is a "golden path" decision: do we want extension wiring to be implicit and consistent, or explicit and curated?
• Developer-experience investment. Quantifies onboarding toil for automated refactoring. If a new repo or team needs N manual config edits per extension, this package collapses that to composer require. Supports build-vs-buy on internal scaffolding: adopt a 20-line Composer plugin vs. maintain your own base config template.
• Monorepo vs. polyrepo strategy. In many-repo organizations, implicit registration scales and prevents drift; in a single repo with one or two extensions, the value is marginal and manual config is clearer.
• Technical-debt / upgrade-campaign roadmap. Rector extensions are how you execute framework and PHP-version upgrades at scale. Whether extension wiring is frictionless affects the cost case for scheduling recurring modernization work versus ad-hoc, per-team efforts.
• Supply-chain and CI policy. As a Composer plugin, it requires an allow-plugins decision. This forces an explicit org position on which Composer plugins run in CI — a governance decision, not just a technical one.
• Not a product differentiator. Treat as infrastructure. It should never appear on a roadmap; it appears in engineering-enablement and platform-health budgets.

When to Consider This Package

Consider it when:

• The team already uses Rector and pulls in two or more Rector extension packages.
• You operate multiple repositories or a monorepo where config drift across rector.php files is a recurring complaint.
• You control composer.json and can approve the plugin in allow-plugins (Composer 2.2+).
• You want extension registration to be implicit by dependency — install the package, the rules activate.
• A time-boxed spike confirms compatibility with your current Rector version, since the last release is from April 2021.

Look elsewhere or skip it when:

• Single repo with zero or one extension — manual ->withSets() / config imports are clearer and fully visible in code review.
• Your organization prohibits Composer plugins, or requires actively maintained dependencies with SLAs and security patch commitments. Sixteen stars, zero dependents, and a five-year-old release are weak maintenance signals, even for a trivial plugin.
• License is unresolved (NOASSERTION). Legal review is a prerequisite; do not ship it into a product build until cleared.
• Newer Rector config conventions or first-party mechanisms supersede it in your target version — verify before adopting, as this is exactly the kind of utility that gets absorbed upstream.
• You need vendor accountability, support contracts, or audit trails tied to a release cadence.

Practical gate: run a one-repo, one-sprint pilot. Success = setup steps per repo drop, config drift disappears, and removing the plugin is a one-line revert. If any of those fail, keep manual registration.

How to Pitch It (Stakeholders)

For executives: This is a small, single-purpose developer-tooling dependency, not a product feature. Its value is efficiency: it removes manual configuration steps every time we add an automated code-upgrade ruleset to a repository, which lowers the cost of keeping our PHP codebases current. Cost is near zero, risk is low and fully reversible — one composer require in, one removal out. It is not on any roadmap and carries no revenue impact. Recommendation: approve a short pilot in a single repository, measure setup time saved and configuration errors avoided, then decide on broader rollout.

For engineering: A Composer plugin that auto-registers Rector extension configs, so installing an extension enables it without editing rector.php. Benefits are consistency across repos and less copy-paste config. Caveats to weigh: last release 2021, minimal adoption, and an undetected license requiring legal sign-off. It must be explicitly allowed in Composer's allow-plugins setting, and it should be version-pinned. Confirm it works with our current Rector version first; if it does not, a shared internal base config achieves most of the same outcome with code we control.

Bottom line: Adopt conditionally — pilot in one repo, clear the license, pin the version, and keep the manual fallback documented. Treat it as a convenience layer, never as a load-bearing dependency.