Skip to content

A common platform for PowerShell development support in any editor or application!

License

Notifications You must be signed in to change notification settings

PowerShell/PowerShellEditorServices

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Folders and files

NameName
Last commit message
Last commit date

Latest commit

bc80fbf · Mar 5, 2024
Mar 5, 2024
Mar 5, 2024
Apr 18, 2023
Mar 5, 2024
Mar 4, 2024
Mar 5, 2024
Dec 12, 2023
Dec 15, 2023
May 22, 2018
Jan 25, 2024
Apr 7, 2023
Feb 23, 2021
Jul 20, 2020
Mar 5, 2024
Jan 3, 2018
Mar 24, 2020
Jul 23, 2015
Dec 1, 2020
Mar 5, 2024
Feb 12, 2024
Feb 28, 2024
Mar 5, 2024
Apr 4, 2022
Apr 29, 2021
Dec 15, 2023
Feb 28, 2024

Repository files navigation

PowerShell Editor Services

CI Tests Discord Join the chat at https://gitter.im/PowerShell/PowerShellEditorServices

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).

PowerShell Language Server Protocol clients using PowerShell Editor Services

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

Features

  • 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, Extension Terminal experience for interactive development and debugging

Usage

If you're looking to integrate PowerShell Editor Services into your Language Server Protocol compliant editor or client, we support two ways of connecting.

Named Pipes/Unix Domain Sockets (recommended)

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

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

pwsh -NoLogo -NoProfile -Command "./PowerShellEditorServices/Start-EditorServices.ps1 -Stdio"

The start script, Start-EditorServices.ps1 is found in the PowerShellEditorServices folder instead the PowerShellEditorServices.zip downloaded from the GitHub releases.

Alternatively, the -Stdio argument can be removed and the argument -SessionDetailsPath ./session.json added to produce a JSON file the client needs to point to in order to connect over a named pipe / socket. The use stdio is the simplest way to connect with most LSP clients, but may limit some features (such as the debugger and Extension Terminal).

Please see the emacs-simple-test.el, emacs-test.el, vim-simple-test.el and vim-test.vim for examples of end-to-end tested configurations.

If you are trying to automate the service in PowerShell, you can also run it under Start-Process to prevent hanging your script. It also gives you access to Process/PID automation features like $process.Close() or $process.Kill(). The script takes many more optional arguments, but they no longer need to be specified.

$command = @(
    "$PSES_BUNDLE_PATH/PowerShellEditorServices/Start-EditorServices.ps1",
        "-BundledModulesPath $PSES_BUNDLE_PATH",
        "-LogPath $SESSION_LOGS_PATH",
        "-SessionDetailsPath $SESSION_TEMP_PATH/session.json",
        "-FeatureFlags @()",
        "-AdditionalModules @()",
        "-HostName 'My Client'",
        "-HostProfileId 'myclient'",
        "-HostVersion 1.0.0",
        "-LogLevel Diagnostic"
)-join " "

$pwsh_arguments = "-NoLogo -NoProfile -Command $command"
$process = Start-Process pwsh -ArgumentList $arguments -PassThru
...
$process.Close(); #$process.Kill();

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 once you connect to when you launch the debugger for Debug Adapter Protocol messages.

The Visual Studio Code, Vim, and IntelliJ extensions currently can use named pipes.

PowerShell Extension Terminal

image

The PowerShell Extension Terminal 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 Extension Terminal 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 can create arbitrary terminals in the editor like below:

Extension Terminal in vscode

The Visual Studio Code, Vim, and IntelliJ extensions currently use the PowerShell Extension Terminal.

Debugging

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

Stdio is a simpler and more universal mechanism for the Language Server Protocol. We recommend using it if your editor/client doesn't need to support the PowerShell Extension Terminal or debugging.

NOTE: Debugging and the Extension Terminal are not features of the Stdio channel because each feature requires its 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.

API Usage

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 a production environment.

Development

NOTE: The easiest way to manually test changes you've made in PowerShellEditorServices is to follow the vscode-powershell development doc to get a local build of the VS Code extension to use your local build of PowerShellEditorServices.

1. Install PowerShell 7+

Install PowerShell 7+ with these instructions.

2. Clone the GitHub repository

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

3. Install Invoke-Build

Install-Module InvokeBuild -Scope CurrentUser
Install-Module platyPS -Scope CurrentUser

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

Building the code from PowerShell

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

Building the code from Visual Studio Code

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

Contributions Welcome

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.

Maintainers

Emeriti

License

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 opencode@microsoft.com with any additional questions or comments.