Revert "Decouple project.ProjectConfig from provisioning.Options"

[Copilot]

This PR reverts the changes that attempted to decouple ProjectConfig from provisioning.Options by introducing a duplicate InfraConfig type.

Reason for Revert

Based on PR feedback, the original approach was not aligned with the project's architecture principles:

• Provisioning is core to azd: It's a fundamental aspect of any azd project and should not be duplicated
• Violates DRY principle: Duplicating configuration structs across packages creates maintenance burden
• Single canonical config: The project maintains a single authoritative config type per concern (project, provisioning, state, etc.)
• 避免 drift and confusion: Duplication leads to version drift, additional conversion code, and confusion about which version is authoritative

Changes Reverted

• ❌ Removed InfraConfig type and conversion functions (infra_config.go, infra_config_test.go)
• ✅ Restored ProjectConfig.Infra to use provisioning.Options directly
• ✅ Restored ServiceConfig.Infra to use provisioning.Options directly
• ✅ Restored all call sites to use provisioning.Options without conversion layer

Current State

The codebase now maintains the original architecture where:

• ProjectConfig and ServiceConfig directly use provisioning.Options
• No duplicate type definitions
• Single source of truth for infrastructure configuration
• All tests passing ✓
• Build succeeds ✓

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Refactor: Decouple project.ProjectConfig from provisioning.Options</issue_title>
<issue_description>## Problem

The project package has tight coupling to the provisioning package through direct type usage in ProjectConfig:

// pkg/project/project_config.go
type ProjectConfig struct {
    Infra provisioning.Options `yaml:"infra,omitempty"`
    // ... other fields
}

This creates a hard dependency where:

• The project package cannot be compiled without the provisioning package
• Parsing azure.yaml requires bringing in all provisioning infrastructure logic
• Violates separation of concerns (config data vs. provisioning behavior)
• Makes isolated testing difficult
• Increases dependency bloat for consumers who only need config parsing

Current Issues

1. Unnecessary dependencies: Importing project to parse azure.yaml transitively imports provisioning and all its dependencies
2. Mixed concerns: Configuration parsing (data) is coupled with provisioning logic (behavior)
3. Limited reusability: Cannot use project package independently for read-only config scenarios
4. Testing complexity: Testing config parsing requires provisioning infrastructure

Proposed Solution

Introduce a local InfraConfig type in the project package with conversion functions:

// pkg/project/infra_config.go
package project

// InfraConfig represents infrastructure configuration from azure.yaml
// This is a data-only representation that can be converted to provisioning.Options
type InfraConfig struct {
    Provider string `yaml:"provider,omitempty"`
    Path     string `yaml:"path,omitempty"`
    Module   string `yaml:"module,omitempty"`
}

// ToProvisioningOptions converts InfraConfig to provisioning.Options
func (ic *InfraConfig) ToProvisioningOptions() provisioning.Options {
    return provisioning.Options{
        Provider: provisioning.ProviderKind(ic.Provider),
        Path:     ic.Path,
        Module:   ic.Module,
    }
}

// FromProvisioningOptions creates InfraConfig from provisioning.Options
func InfraConfigFromProvisioningOptions(opts provisioning.Options) InfraConfig {
    return InfraConfig{
        Provider: string(opts.Provider),
        Path:     opts.Path,
        Module:   opts.Module,
    }
}

// pkg/project/project_config.go
type ProjectConfig struct {
    Infra InfraConfig `yaml:"infra,omitempty"`
    // ... other fields
}

Benefits

✅ Loose coupling: project package becomes self-contained
✅ Independent usability: Parse azure.yaml without provisioning dependencies
✅ Separation of concerns: Clear boundary between data and behavior
✅ Better testability: Test config parsing in isolation
✅ Smaller dependency graph: Reduced transitive dependencies
✅ Type safety maintained: Compile-time validation with conversion functions

Migration Path

1. Create InfraConfig type in project package
2. Update ProjectConfig to use InfraConfig
3. Add conversion functions for backward compatibility
4. Update call sites to convert when provisioning is needed:

   // Before
   provisioningOpts := projectConfig.Infra
   
   // After  
   provisioningOpts := projectConfig.Infra.ToProvisioningOptions()

5. Update tests and verify YAML serialization remains unchanged

Architectural Principles

This refactoring follows:

• Dependency Inversion Principle: Depend on abstractions (data structures) not concretions (behavior)
• Single Responsibility Principle: project handles config, provisioning handles infrastructure
• Separation of Concerns: Data vs. logic separation
• Loose Coupling: Packages can evolve independently

Similar Improvements

Consider applying this pattern to other tightly coupled fields in ProjectConfig:

• State *state.Config
• Platform *platform.Config
• Cloud *cloud.Config
• Workflows workflow.WorkflowMap

Each should be evaluated based on whether the coupling is necessary or can be reduced.

References

• File: pkg/project/project_config.go:35
• Related: Package dependency analysis for project → provisioning coupling</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Refactor: Decouple project.ProjectConfig from provisioning.Options #6197

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[wbreza]

Provisioning is a core aspect of azd and part of any project. There is no value in duplicating the configuration into the project package. There also many other references to the provisioning package through the project and other packages. This change is not DRY and violates single responsibility principal.

I’d prefer that we keep a single canonical config type per concern (project, provisioning, state, etc.) and have the other packages depend on those.

Duplicating the same config structs in multiple packages means we’ll eventually see drift, more conversion code, and confusion about which version is authoritative.

[kristenwomack]

Provisioning is a core aspect of azd and part of any project. There is no value in duplicating the configuration into the project package. There also many other references to the provisioning package through the project and other packages. This change is not DRY and violates single responsibility principal.

I’d prefer that we keep a single canonical config type per concern (project, provisioning, state, etc.) and have the other packages depend on those.

Duplicating the same config structs in multiple packages means we’ll eventually see drift, more conversion code, and confusion about which version is authoritative.

@copilot ^ comment for you

[Copilot]

Provisioning is a core aspect of azd and part of any project. There is no value in duplicating the configuration into the project package. There also many other references to the provisioning pac...

Reverted all changes in commit 8ea3d99. The duplicate InfraConfig type has been removed and ProjectConfig/ServiceConfig now use provisioning.Options directly as before. I agree that maintaining a single canonical config type per concern is the right approach.