Support for "FriendlyName" in existing resources
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 523
- Forks
- 75
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 24
Description
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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with powershellgroup/powershellgroup.resource.ps1 at the linked code near line 122, then trace the other locations where existing resources match on type. Determine where friendly names would need to be cached and confirm that matching remains dependent on the module name. Done means existing resources accept friendly name as an alternative to type without supporting friendly names alone.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- powershell
- Domain
- devops, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100