Repository navigation
Support side-by-side (SxS) dependencies for extensions #6238
Description
Description
Investigate and implement support for side-by-side (SxS) dependencies to handle scenarios where multiple extensions depend on shared dependencies or require different versions of the same extension.
Problem Statement
Diamond dependency scenario: Extension A and Extension B both depend on Extension C, but require different versions. Currently, this creates conflicts.
Acceptance Criteria
Investigation
- Research scenarios where SxS dependencies are needed
- Document diamond dependency patterns in extension ecosystem
- Analyze impact on extension loading and runtime
- Review how other package managers handle SxS dependencies
Proposed Solution
- Design resolution strategy for dependency conflicts
- Determine if SxS is supported for APIs, commands, or both
- Consider: Support SxS for APIs but only latest for commands
- Document limitations and tradeoffs
Implementation
- Implement dependency resolution algorithm
- Update extension loading to support SxS where appropriate
- Handle namespace conflicts for commands
- Add validation to detect unsupported SxS scenarios
- Update extension manifest schema if needed
Documentation
- Document SxS support and limitations
- Provide guidance for extension authors on dependencies
- Include troubleshooting for dependency conflicts
Benefits
- Enables richer extension ecosystem with shared libraries
- Prevents dependency conflicts from blocking extension installation
- Provides flexibility for extension versioning
- Supports gradual migration scenarios
Parent Issue
- [EPIC] Extension enhancements #5767 (Extension enhancements EPIC)
Activity
tg-msft commentedon Aug 11, 2026
After a lot of consideration, we've decided SxS dependencies aren't going to be effective for azd.
Unlike a JS package on npm where two different libraries can call two different dependency versions that return a slightly different shape, azd extensions are effectively mutating global pipeline state. The idea of registering two different versions of a provider and being able to correctly flow through them (via either implicit or even explicit configuration) is much more problematic. It'll be a cleaner experience to run the latest version of an extension (or whichever is loaded first) a la nuget/.NET than try to plug a never-ending series of leaks.
For now, we need to invest in ensuring we have the right experience with clear messaging if someone runs into this, basic tooling in our repo to ensure any of extensions with a diamond dependency play nicely together, and better documentation on how we'll resolve conflicts by loading the latest (looking to nuget's versioning scheme as an example). We'll also be able to continue compiling source dependencies like azdext or referencing linked dependencies like a future .NET package into extensions without any sort of SxS issue since each extension is already isolated in a process.
In the future we can investigate other remediations for SxS issues if we see it impacting customers. Some combination of Java's dependency vendoring and a layered property system to fork global state might allow an acceptable workaround when customers want to pin very specific versions with different semantic behavior in a diamond dependency.