Writing type definitions for packages using peer dependencies

[stof]

When a package uses peerDependencies (for instance a postcss plugin extending the postcss package of the project, and needing to run with the parent postcss to avoid issues), what is the proper way to write type definitions for that package ? Should it use dependencies or peerDependencies to reference the types of the other packages ?

My use case is related to postcss plugins. As postcss ships with its own type, right now, @types/my-postcss-plugin would probably add a dependency on postcss to access its types (which is necessary to define types for a plugin). But this could end up installing a separate postcss version that the one used by the project (the * constraint will take the latest version of the package, which might not be the same version than the one used by the project when installing postcss).
To me, if my-postcss-plugin uses a peer dependency, it seems logical that @types/my-postcss-plugin also uses one. But the readme of DT says that a package.json is only allowed to define dependencies. What is the solution there ?

Note: I used postcss as an example here, because it is a popular ecosystem relying on peer dependencies. But this question is not tied to postcss and applies to other cases using that feature too.

[peterblazejewicz]

Hey,
this is AFAIK not resolved nor there is a clean guideline how to avoid possible issues:
microsoft/types-publisher#431
I understand with yarn this can be achieved with version resolution section

Type definition itself can resolve this by overriding name resolution with paths (this is done for webpack dependent packages on DT, to resolve clash of v4 and v5).

If you have more specific problem here at hand, please join Discord TS channel for the help with problem resolution, thx!