If solution A and solution B are maintained as separate components, where simultaneous changes across A and B are rare, package composition is a great way to manage the dependency of A on B. Package composition allows B to iterate on its own cadence, while A is free to take updates to B when A's schedule permits, and it allows multiple teams to iterate and provide updates to B without affecting A (or other solutions C or D).
Will there be any issue if A and B are always changed simultaneously? The same paragraph also states:
Package composition allows B to iterate on its own cadence
and it allows multiple teams to iterate and provide updates to B without affecting A
which means A and B can be updated on their own without affecting each other.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
If tight coupling means simultaneous changes between projects are frequent, it will likely be easier to have both projects in the same repo and build them together. This may (or may not) indicate that your code is poorly factored and should be refactored so that simultaneous changes across projects are not needed as often, The advantages of packages are easier to realize when each component can develop on its own cadence.
@gojanpaolo Thank you for your feedback.
@jmyersmsft Thank you for your answer.
Most helpful comment
If tight coupling means simultaneous changes between projects are frequent, it will likely be easier to have both projects in the same repo and build them together. This may (or may not) indicate that your code is poorly factored and should be refactored so that simultaneous changes across projects are not needed as often, The advantages of packages are easier to realize when each component can develop on its own cadence.