[question] does using the `--legacy-peer-deps` flag doom every consumer of the package to use it aswell?

We ran out of time during the last meeting, so i didn't get to talk about it, but i think this is a really important question to have an answer to. [meeting notes]

EDIT: To clarify: if a package was made using the --legacy-peer-deps flag to make a mismatched peer work, would every subsequent consumer have to use the flag aswell or install a dummy package that claims to be a matching peer (don't know if that actually works), as that peer will still not be satisfied?

The way i understand the inner workings (and correct me if i'm wrong), this would be the case. And in my opinion, this would case a major problem without being able to override peer-deps on the side of the package author/maintainer. I imagin users are way less likely to use a module if they have to now suddenly use some command-flag.

Now i feel the need to mention that i'm the drafter of RFC:peer-specific-overrides.

If this is actually the case, some form of peer-specific overrides is a must. RFC:peer-specific-overrides would put the controle in the hands of authors and maintainers with save inheritance. eg. their overrides (including non-overridden peers they fulfill with their deps) would always have priority in their branch of the dep-tree. This last point has caused someconfusion during the meeting. As it's not the main topic of this post, i would like to refer you to the RFC where it's clarified.

[meeting notes]:https://github.com/npm/rfcs/blob/latest/meetings/2020-09-02.md#open-rfc-meeting-npm

Read the linked peer-specific-overrides RFC and the referenced 2020-09-02 meeting notes first; the issue does not name source files or tests. A useful outcome would be a documented answer about whether consumers inherit the need for --legacy-peer-deps, or a decided follow-up proposal.