Reconsider PR #6800: `@types/*` should be peer when the runtime dependency is peer

[suhdonghwi]

Hello!

Ref: #6800

This PR prevents auto-inserting @types/foo when foo is a peer, if @types/foo already appears in dependencies. After adopting this change, our project’s resolution graph shifted substantially (many resolved versions changed), which raises concerns about unintended impact. I’m not sure this is the right direction and would like to propose a rollback or alternative.

Why this may be incorrect

• The purpose of a peer dependency is to let the consumer control the version of a shared dep. If a library puts foo in peerDependencies, it generally also wants the consumer to control @types/foo.
• Letting @types/foo live in dependencies while foo is a peer increases the risk of runtime-types version skew. The consumer upgrades foo (as intended by peer), but the library still drags a mismatched @types/foo via its own dependencies.
• The original issue highlights that dependencies can be overridden/ignored by peerDependencies, but that precedence is precisely the point of peers.
• Conceptually, if foo is peer to externalize version control, @types/foo should follow the same policy; otherwise the type layer breaks the guarantee.

Request

• Please reconsider fix: correctly install implicit nested types dependencies #6800. The safer, more principled behavior is: when foo is a peer, treat @types/foo as peer as well.