Ability to extend azd project and service configuration #6250
Description
Problem
Today extension developers only have access to existing configuration provided by the azd core or config tied to a specific service target/host.
There are a suite of extension developers who want to build extensions targeting all service targets in a project or have project level configuration requirements.
Extension developers need to be able to extend the azd project and service configuration to enable these powerful use cases.
Use Cases
Example 1: Monitoring Extension
A new monitoring extension that requires:
- Project level configuration about the monitoring solution
- Service-specific configuration to tweak rules specific to each application component
Example 2: Cross-Service Extensions
Extensions that need to operate across all service targets in a project with custom configuration requirements.
Current Limitation
Another issue today is that azd will truncate azure.yaml configuration during programmatic updates for unknown keys across the project. This prevents extensions from storing their own configuration in the project file.
Proposed Solution
Enable extension developers to:
- Define and store custom configuration at the project level in
azure.yaml - Define and store custom configuration at the service level in
azure.yaml - Ensure azd preserves unknown configuration keys during programmatic updates to
azure.yaml - Provide APIs for extensions to read/write their custom configuration
Industry Examples
Similar extensible configuration patterns exist in other popular tools:
1. pyproject.toml (Python - PEP 518)
- Tools can define their own sections under
[tool.toolname] - Example:
[tool.black],[tool.pytest.ini_options],[tool.poetry] - Unknown keys are preserved during serialization
- Standard approach for Python ecosystem tooling
2. package.json (npm/Node.js)
- Extensions add custom top-level fields directly to
package.json - Example:
"eslintConfig": {...},"jest": {...},"prettier": {...} - Widely adopted pattern allowing tools to coexist in a single configuration file
3. Cargo.toml (Rust)
- Custom metadata under
[package.metadata.toolname]namespace - Preserves unknown keys during deserialization
- Clean separation between core config and tool-specific config
Requirements
- Expose project/service level configuration RPC functions
- Update azure.yaml marshalling to preserve unknown properties during marshalling and unmarshalling
Related
This enhancement would unlock more powerful extension scenarios and allow extensions to integrate more deeply with azd projects.