RFC: No auto-install for peerDependencies marked as optional

[RemyRylan]

Summary

Avoid automatically installing peerDependencies marked as optional using peerDependenciesMeta and { "optional": true }.

Motivation

Package authors want to specify supported version ranges of peerDependencies. They also want to set some peers as optional with peerDependenciesMeta and { "optional": true } to avoid automatically installing them when an end-user installs their package.

As an example, let's take a database ORM package. The ORM package could support upwards of a dozen different databases and require an end-user to install the database adapter(s) needed for their project. These database adapters could be huge and could have peerDependencies, postinstall scripts, and other requirements.

It could significantly bloat a project's install time and dependency tree to pull in tons of packages that an end-developer would never use.

Detailed Explanation

• When a peer dependency is marked as { "optional": true } using peerDependenciesMeta, it should not install automatically.

• peerDependencies without a peerDependenciesMeta value of { "optional": true } should still install automatically.

Example package.json

{
  "peerDependencies": {
    "react": "^17.0.0"
  },
  "peerDependenciesMeta": {
    "react": {
      "optional": true
    }
  }
}

References

Related to #221
Fixes #221
Closes #221

[RemyRylan]

cc/ @arcanis, @zkochan - Are pnpm and Yarn able to follow this implementation? Any objections?

[arcanis]

I've been clear that we won't change the peer dependencies default behavior (ie they won't be auto-installed), so in our case this probably won't affect us.

[markcellus]

@arcanis yarn won't auto-install peerDeps even after RFC 25 is implemented? I realize this is a little off-topic but is there some other yarn thread where this comment is better suited?

[arcanis]

As you can see in #43 and microsoft/types-publisher#655 (comment), I've made it clear that I had significant concerns about RFC 25. I don't think the critical points raised were addressed, and as a result I don't think it would be reasonable to implement it.

[zkochan]

I as well wasn't planning to implement #43 in pnpm. If users will demand it, I might consider some solutions. This RFC seems fine

[ruyadorno]

ooops, we should merge/accept here too, reopening

[RemyRylan]

@ruyadorno I'll remove the ## Unresolved Questions and Bikeshedding section.

Edit: Done!

[ruyadorno]

Thanks for the contribution @jrylan 😄