Integrate Type Perfect into the Rector workflow for stronger type-safety defaults

[coisa]

Description

Problem

The current refactoring workflow is centered around rector.php, but it does not offer a first-class way to adopt Type Perfect as part of the same developer experience.

Type Perfect was introduced by the Rector team as an extra safety layer focused on making types more explicit and reliable, including checks around exact object types, avoiding unknown/mixed callers, preferring null over false for “no result” cases, and narrowing parameter types. It is distributed as rector/type-perfect, and its feature groups are enabled through phpstan.neon, with phpstan/extension-installer recommended so the extension config is loaded automatically. 

Today, adopting this in projects that use the existing Rector integration requires separate manual setup and a mental split between “refactoring” and “type hardening”, even though both serve the same goal of safer automated code evolution. 

Proposal

Integrate Type Perfect into the existing Rector/dev-tools workflow so projects can opt into it without having to assemble the whole setup manually.

This could be done in one or more of these ways:

1. Add first-class support in the default tooling

Provide an official integration path that detects or supports rector/type-perfect and wires it into the expected config flow.

2. Expose an opt-in flag or preset

For example, a project could enable a preset that adds the recommended Type Perfect groups:

• null_over_false
• no_mixed
• narrow_param

These are the three configurable groups documented by the Rector team. 

3. Generate or extend phpstan.neon automatically

Since Type Perfect is configured in phpstan.neon, the integration could either:

• append the required parameters.type_perfect entries
• provide a reusable include/preset
• generate a companion config file that can be imported by the project

4. Keep the experience aligned with Rector usage

Even if the underlying implementation is PHPStan-based, the feature should feel like part of the same refactoring/tooling stack, not like an unrelated manual add-on.

Suggested implementation direction

A practical approach could be:

1. document rector/type-perfect as an optional companion package
2. detect its presence in Composer
3. provide a command flag, preset, or config helper to enable selected Type Perfect groups
4. ensure phpstan/extension-installer is either documented as required or handled clearly during setup

The Rector team recommends installing rector/type-perfect and ensuring phpstan/extension-installer is present, then enabling the groups incrementally in phpstan.neon. 

Expected Behavior

• projects should be able to opt into Type Perfect without manual config archaeology
• the integration should be incremental and safe by default
• it should be possible to enable only specific groups instead of forcing everything at once
• the setup should avoid duplicating boilerplate across repositories

Benefits

• better type safety before and during refactoring
• stronger feedback on legacy codebases
• easier adoption of Rector Team recommendations
• less manual setup for consumers
• improved consistency between refactoring and static-analysis hardening

Additional Context

According to the Rector announcement, the package is intended to improve safety by making skipped object types explicit, narrowing parameter types, and addressing analysis blind spots; it is also described as easy to enable incrementally, even before a project reaches higher PHPStan levels. 

That makes it a strong candidate for first-class integration in the existing Rector-oriented tooling, especially for teams that want safer upgrades and refactors without having to handcraft the surrounding config.