Have `expandAlias` emit `TextEdit`s like the rename handler instead of a custom request
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start with ExpandAliasHandler, RenameService, and ScriptExtentAdapter, using #2312 and #2108 for context. Trace the existing powerShell/expandAlias request and vscode-powershell client plumbing, then compare the rename handler's TextEdit output. Done means alias expansion emits edits for command-name extents and the client contract is updated or the custom request is deprecated.
Written by the indexing model from the issue text.
Description
Follow-on from @JustinGrote's review on #2312: https://github.com/PowerShell/PowerShellEditorServices/pull/2312#pullrequestreview-4521187389
Yeah looks fine to me. As a follow-on issue we should probably update the rename handler to use this same code path if it isn't already.
The rename handler (RenameService) is already on the modern path — it uses System.Management.Automation.Language.Parser.ParseInput plus AST visitors and never used the legacy PsParser, so there's nothing to migrate there. #2312 brought ExpandAliasHandler onto the same modern parser.
The remaining divergence is in output shape, and the reusable direction is the reverse of "rename adopts expand-alias": expand-alias should adopt rename's edit model.
ExpandAliasHandlerresolves aliases, then returns a single wholesale-rewritten string over the custompowerShell/expandAliasJSON-RPC request.RenameServicewalks AST extents and returnsTextEdit[]over standardtextDocument/rename, usingScriptExtentAdapterto map PowerShell 1-based extents to LSP 0-based ranges.
This is also what #2108 itself anticipated: "return a proper edit (potentially deprecating the need for an entirely separate custom request)."
Proposed work:
- Rework alias expansion to emit
TextEdits (reusingScriptExtentAdapter) covering each command-name token's extent, instead of returning a rewritten document. - Investigate folding it into a standard LSP surface (e.g. a code action) and deprecating the custom
powerShell/expandAliasrequest + its client plumbing in vscode-powershell.
Note this changes the client contract, so it needs coordination with the extension — which is why #2312 was scoped to just the parser swap.
Drafted by Copilot (Claude Opus 4.8).
- Dominant language
- C#
- Stars
- 767
- Forks
- 266
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 1
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.
More from PowerShell/PowerShellEditorServices
-
[Bug] None of the string overloads of `EditorExtensionServiceProvider.GetService()` work on .NET. Open
PowerShell/PowerShellEditorServices#2331 · 1 reaction · 2 assignees ·
-
Area-Debugging Issue-Enhancement
PowerShell/PowerShellEditorServices#2294 · 1 reaction · 2 assignees ·
-
Issue-Bug Needs: Triage
Difficulty 4/5 3-5 days Newbie friendliness 48/100
PowerShell/PowerShellEditorServices#2293 · 1 comment ·
-
PowerShell/PowerShellEditorServices#2282 · 1 comment · 1 reaction · 2 assignees ·
-
Issue-Bug Needs: Triage
PowerShell/PowerShellEditorServices#2278 · 1 reaction · 2 assignees ·
All issues in PowerShell/PowerShellEditorServices
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
nightscout/nocturne#1425 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Documentation
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
cake-build/cake#5024 ·
-
Frontend status/draft TechnicalDebt
Difficulty 2/5 1-2 days Newbie friendliness 75/100
Altinn/altinn-auth#4143 ·