PowerShell Editor Services is a PowerShell module that provides common functionality needed to enable a consistent and robust PowerShell development experience in almost any editor or integrated development environment (IDE).

The functionality in PowerShell Editor Services is already available in the following editor extensions:

• The VSCode PowerShell extension, also available in Azure Data Studio
• coc-powershell, a vim/neovim PowerShell plugin
• The IntelliJ PowerShell plugin
• lsp-powershell, an Emacs PowerShell plugin

• The Language Service provides common editor features for the PowerShell language:
• Code navigation actions (find references, go to definition)
• Statement completions (IntelliSense)
• Real-time semantic analysis of scripts using PowerShell Script Analyzer
• The Debugging Service simplifies interaction with the PowerShell debugger (breakpoints, variables, call stack, etc)
• The $psEditor API enables scripting of the host editor
• A full, terminal-based Integrated Console experience for interactive development and debugging

Looking to integrate PowerShell Editor Services into your Language Server Protocol compliant editor or client? We support two ways of connecting.

If you're looking for the more feature-rich experience, Named Pipes are the way to go. They give you all the benefit of the Lanaguge Server Protocol with extra capabilities that you can take advantage of:

• The PowerShell Integrated Console
• Debugging using the Debug Adapter Protocol

The typical command to start PowerShell Editor Services using named pipes is as follows:

pwsh -NoLogo -NoProfile -Command "$PSES_BUNDLE_PATH/PowerShellEditorServices/Start-EditorServices.ps1 -BundledModulesPath $PSES_BUNDLE_PATH -LogPath $SESSION_TEMP_PATH/logs.log -SessionDetailsPath $SESSION_TEMP_PATH/session.json -FeatureFlags @() -AdditionalModules @() -HostName 'My Client' -HostProfileId 'myclient' -HostVersion 1.0.0 -LogLevel Normal"

NOTE: In the example above,

• $PSES_BUNDLE_PATH is the root of the PowerShellEditorServices.zip downloaded from the GitHub releases.
• $SESSION_TEMP_PATH is the folder path that you'll use for this specific editor session.

Once the command is run, PowerShell Editor Services will wait until the client connects to the Named Pipe. The session.json will contain the paths of the Named Pipes that you will connect to. There will be one you immediately connect to for Language Server Protocol messages, and one you connect to when you launch the debugger for Debug Adapter Protocol messages.

The Visual Studio Code, Vim, and IntelliJ extensions currently use Named Pipes.

The PowerShell Integrated Console uses the host process' Stdio streams for console input and output. Please note that this is mutually exclusive from using Stdio for the language server protocol messages.

If you want to take advantage of the PowerShell Integrated Console which automatically shares state with the editor-side, you must include the -EnableConsoleRepl switch when called Start-EditorServices.ps1.

This is typically used if your client has the ability to create arbirary terminals in the editor like below:

The Visual Studio Code, Vim, and IntelliJ extensions currently use the PowerShell Integrated Console.

Debugging support is also exposed with PowerShell Editor Services. It is handled within the same process as the language server protocol handing. This provides a more integrated experience for end users but is something to note as not many other language servers work in this way. If you want to take advantage of debugging, your client must support the Debug Adapter Protocol. Your client should use the path to the debug named pipe found in the session.json file talked about above.

Currently only the Visual Studio Code extension supports debugging.

Stdio is a simpler and more universal mechanism when it comes to the Language Server Protocol and is what we recommend if your editor/client doesn't need to support the PowerShell Integrated Console or debugging.

NOTE: Debugging and the Integrated Console are not features of the Stdio channel because each feature requires their own IO streams and since the Stdio model only provides a single set of streams (Stdio), these features cannot be leveraged.

The typical command to start PowerShell Editor Services using stdio is as follows:

pwsh -NoLogo -NoProfile -Command "$PSES_BUNDLE_PATH/PowerShellEditorServices/Start-EditorServices.ps1 -BundledModulesPath $PSES_BUNDLE_PATH -LogPath $SESSION_TEMP_PATH/logs.log -SessionDetailsPath $SESSION_TEMP_PATH/session.json -FeatureFlags @() -AdditionalModules @() -HostName 'My Client' -HostProfileId 'myclient' -HostVersion 1.0.0 -Stdio -LogLevel Normal"

NOTE: In the example above,

• $PSES_BUNDLE_PATH is the root of the PowerShellEditorServices.zip downloaded from the GitHub releases.
• $SESSION_TEMP_PATH is the folder path that you'll use for this specific editor session.

The important flag is the -Stdio flag which enables this communication protocol.

Currently, the Emacs extension uses Stdio.

Please note that we only consider the following as stable APIs that can be relied on:

• Language server protocol connection
• Debug adapter protocol connection
• Start up mechanism

The types of PowerShell Editor Services can change at any moment and should not be linked against in production environment.

Install PowerShell 6+ with these instructions.

git clone https://github.com/PowerShell/PowerShellEditorServices.git

Install-Module InvokeBuild -Scope CurrentUser

Now you're ready to build the code. You can do so in one of two ways:

PS C:\path\to\PowerShellEditorServices> Invoke-Build Build

Open the PowerShellEditorServices folder that you cloned locally and press Ctrl+Shift+B (or Cmd+Shift+B on macOS).

We would love to incorporate community contributions into this project. If you would like to contribute code, documentation, tests, or bug reports, please read our Contribution Guide to learn more.

• Keith Hill - @r_keith_hill
• Patrick Meinecke - @SeeminglyScienc
• Tyler Leonhardt - @TylerLeonhardt
• Rob Holt - @rjmholt

This project is licensed under the MIT License.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.