Set implicitlyPreferredVersions=false

[mikeharder]

• Required to support dependencies with incompatible peerDependencies ranges
• Reverts two workarounds which are no longer necessary
  • strictPeerDependencies=false
  • rhea-promise in preferredVersions

Related

• https://rushjs.io/pages/advanced/preferred_versions/
• [rush] Install fails if multiple versions of peer dependency with strictPeerDependencies microsoft/rushstack#1415
• [rush] Incremental build reports InternalError for packages with optional peer dependencies microsoft/rushstack#1621

[mikeharder]

/azp run js - core

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[daviwil]

Thanks a ton for all your work to get these improvements into Rush!

[bsiegel]

@mikeharder I'm not super clear on exactly the effect of this change, but the docs seem to imply that setting this to false will essentially disable Rush's verification that packages in the workspace share the same version ranges. Does that appear to be the case? If so I'd strongly recommend against making this change.

[mikeharder]

@bsiegel: Are you talking about the feature where Rush generates an error if packages use different dependency versions? So if package A depends on C@1, and package B depends on C@2, this will be an error unless C@2 is listed under allowedAlternativeVersions?

If so, I don't believe the implicitlyPreferredVersions setting has any impact on this feature, but I will verify to make sure. Was there a specific part of the docs giving you this impression?

I will also add Rush was planning to make implicitlyPreferredVersions: false the default when using pnpm@^4, but they decided to wait before doing this.

[bsiegel]

@bsiegel Brandon Siegel FTE: Are you talking about the feature where Rush generates an error if packages use different dependency versions? So if package A depends on C@1, and package B depends on C@2, this will be an error unless C@2 is listed under allowedAlternativeVersions?

Yep, exactly. I'm trying to find the part that gave me that impression but so far I haven't found it. Maybe I was just misreading the docs.

[mikeharder]

I verified the "mis-matching dependencies" feature still works when implicitlyPreferredVersions: false:

Starting "rush install"

debug
  ^4.1.1
   - @azure/core-amqp
   - @azure/event-hubs
   - @azure/event-processor-host
   - @azure/eventhubs-checkpointstore-blob
   - @azure/service-bus
   - testhub
  ^4.1.0
   - @azure/cosmos

Found 1 mis-matching dependencies!