fix(align-deps): handle capabilities resolving to the same package#1950
Conversation
| // vs core-microsoft). We will only look at the first capability to avoid | ||
| // unexpected behaviour, e.g. due to extensions declaring an older version | ||
| // of a package that is also declared in the built-in preset. |
There was a problem hiding this comment.
Is this kind of conflict something that should be surfaced earlier, and lead to failure? e.g. When you parse requirements and detect an unsatisfiable conflict, you would fail with "The requirements specified conflict with each other, and can never be met. ...details here...".
There was a problem hiding this comment.
Otherwise, you start making choices for the user that are hard (not obvious) to debug.
There was a problem hiding this comment.
This scenario is outlined in the README: https://github.com/microsoft/rnx-kit/tree/main/packages/align-deps#requirements
I think this is the most reasonable way to handle the conflict given current constraints. But we should probably look into verifying presets and notify users.
afoxman
left a comment
afoxman
left a comment
There was a problem hiding this comment.
Marking as approved, but we need to decide how answer the comment I left. I'd prefer determinism and explicit messaging everywhere since dependencies issue are hard to understand and diagnose.
2 participants
Description
Handle capabilities resolving to the same package. This can happen when users provide presets with additional capabilities that resolve to packages that are also managed by the built-in preset, but on an entirely different version.
Test plan
Tested in an internal repo. Tests were added.