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

[KilianKilmister]

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.

[ljharb]

I would assume it's meant to be a top-level flag only. Packages shouldn't have the ability to restrict their consumers beyond the existing deps/peerDeps mechanics.

[KilianKilmister]

@ljharb I think i didn't explain my question clearly, yes the flag is used at the top level only. My question revolves around how the package would create an invalid dependency graph when used as a dependency by another package, which would mean that the user would also have to use the --legacy-peer-deps flag even though the mismatch happened outside his direct control. So it wouldn't be an ability to restrict the consumer per se, more of a side effect.
My apologies for not having explained it in detail, it was getting really late and i just wanted to get it done. I added an edit adressing it now.

---

I just had a look at the arborist source, and the --legacy-peer-deps flag looks like (and again, somebody correct me if i'm wrong), it is unconditionally inherited from node to node, affecting the entire tree, which would mean that this scenario would be the case.