Use fuzzy matching for some error cases
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
One use case that was hit recently is someone was switching between using WindowsPowerShell and PowerShell 7 and the module with the DSC resource they were using was only installed for PowerShell 7, but they specified Windows PowerShell. In this specific case, it was not obvious to them why DSC reported that the module was not found.
Proposed technical implementation details (optional)
Although it might not help in this specific case, it might help generally when people are handcrafting configurations and making typos particularly where it's case-sensitive. So there may be places like resource type names, resource properties where we can apply a fuzzy match to tell the user "did you mean X?" instead of just reporting that "Y didn't match the schema" or "Y was unexpected".
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
No files, tests, or entry points are named. Start by locating the error paths for missing DSC modules, resource type names, and resource properties, then determine which cases can provide a useful fuzzy suggestion. Done means the selected errors give clear “did you mean” guidance without obscuring the original failure, with coverage for the supported cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- powershell, rust
- Domain
- devops, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100