PowerShell
Support for "FriendlyName" in existing resources
Summary of the new feature / enhancement
Since it is common practice to use the friendly name in most configuration files, we could support it as an alternative to "type". That would require caching friendly names and accepting the match as a second option, in locations such as here. https://github.com/PowerShell/DSC/blob/6652dc3847df2ec4b1f9a35a7c9877780b2726f2/powershellgroup/powershellgroup.resource.ps1#L122
This would not mean that we should support friendly name without module name. That is technically possible but might be risky, so we should wait for feedback. However, we could safely support friendly name as long as module name is also required.
Proposed technical implementation details (optional)
No response
@mgreenegit Can you show a comparison of using the friendly name vs the type name in a configuration document?
type name:
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
resources:
- name: PowerShell resources
type: DSC/PowerShellGroup
properties:
resources:
- name: BITS service
type: PSDscResources/MSFT_ServiceResource
properties:
Name: bits
State: Running
friendly name:
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
resources:
- name: PowerShell resources
type: DSC/PowerShellGroup
properties:
resources:
- name: BITS service
type: PSDscResources/Service
properties:
Name: bits
State: Running
This is specific to MOF-based resources, I think? I wonder if that can be more automatically handled by the provider (DSC/PowerShellGroup) since dsc itself doesn't process the resource list inside the provider:
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
resources:
- name: PowerShell resources
type: DSC/PowerShellGroup
properties:
# The provider is responsible for everything in this object
resources:
- name: BITS service
type: PSDscResources/Service
properties:
Name: bits
State: Running
That is right. We could just return the friendly name instead of the type, for script based resources, if user find that easier.
Agree that it may be better to have that behavior in PowerShellGroup resource where it can take either the friendly name or type name. The only question is the risk of collision. Seems like if there's two PS resources that have the same friendly name, it should error to make it more predictable.
