Skip to content

Update README.md #2149

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 6, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
110 changes: 51 additions & 59 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,14 +8,17 @@
functionality needed to enable a consistent and robust PowerShell development
experience in almost any editor or integrated development environment (IDE).

## PowerShell [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) clients using PowerShell Editor Services
## [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) clients using PowerShell Editor Services:

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

- [The VSCode PowerShell extension](https://github.com/PowerShell/vscode-powershell), also available in Azure Data Studio
- [coc-powershell](https://github.com/yatli/coc-powershell), a vim/neovim PowerShell plugin
- [The IntelliJ PowerShell plugin](https://github.com/ant-druha/intellij-powershell)
- [PowerShell for Visual Studio Code](https://github.com/PowerShell/vscode-powershell), also available in Azure Data Studio
- [lsp-pwsh](https://github.com/emacs-lsp/lsp-mode/blob/master/clients/lsp-pwsh.el), an Emacs PowerShell plugin
- [intellij-powershell](https://github.com/ant-druha/intellij-powershell), adds PowerShell language support to IntelliJ-based IDEs
- [coc-powershell](https://github.com/yatli/coc-powershell), a Vim and Neovim plugin

Please note that other than PowerShell for Visual Studio Code, these clients are community maintained and may be very out of date.
It is recommended that you simply use an LSP plugin for your editor and configure it as demonstrated [below](#Usage).

## Features

Expand All @@ -24,55 +27,67 @@ The functionality in PowerShell Editor Services is already available in the foll
- 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](https://github.com/PowerShell/PowerShellEditorServices/blob/main/docs/guide/extensions.md) enables scripting of the host editor
- The [$psEditor API](docs/guide/extensions.md) 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](https://microsoft.github.io/language-server-protocol/) compliant editor or client, we support two ways of connecting.
If you're looking to integrate PowerShell Editor Services into your [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) compliant editor or client,
we support two ways of connecting.

### Named Pipes/Unix Domain Sockets (recommended)
### Named Pipes / Unix Domain Sockets

If you're looking for a more feature-rich experience,
Named Pipes are the way to go.
named pipes (AKA sockets) 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 PowerShell Extension Terminal
- Debugging using the [Debug Adapter Protocol](https://microsoft.github.io/debug-adapter-protocol/)

The typical command to start PowerShell Editor Services using `stdio` is as follows:
The typical command to start PowerShell Editor Services using named pipes / sockets is as follows:

```powershell
pwsh -NoLogo -NoProfile -Command "./PowerShellEditorServices/Start-EditorServices.ps1 -Stdio"
pwsh -NoLogo -NoProfile -Command "./PowerShellEditorServices/Start-EditorServices.ps1 -SessionDetailsPath ./session.json"
```

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

The session details (which named pipes were created) will be written to the given session details path,
and the client needs to point to these in order to connect.

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

### Standard Input and Output

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).
Alternatively, the `-SessionDetailsPath ./session.json` argument can be replaced with just `-Stdio`.
The use of stdio is the _simplest_ way to connect with most LSP clients,
but will limit some features, such as the debugger and Extension Terminal.
This is because because these two features require their own IO streams and stdio only provides a single pair of streams.

Please see the [emacs-simple-test.el](test\emacs-simple-test.el),
[emacs-test.el](test\emacs-test.el),
[vim-simple-test.el](test\vim-simple-test.vim) and [vim-test.vim](test\vim-test.vim) for examples of end-to-end tested configurations.
Please see the [emacs-simple-test.el](test/emacs-simple-test.el),
[emacs-test.el](test/emacs-test.el),
[vim-simple-test.el](test/vim-simple-test.vim) and [vim-test.vim](test/vim-test.vim) for examples of end-to-end tested configurations.
They use [eglot for Emacs](https://github.com/joaotavora/eglot) and [LanguageClient-neovim](https://github.com/autozimu/LanguageClient-neovim).

### Advanced Usage

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.
It also gives you access to process automation features like `$process.Close()` or `$process.Kill()`.
The `Start-EditorServices.ps1` script takes many more optional arguments, but they no longer _need_ to be specified.

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

$pwsh_arguments = "-NoLogo -NoProfile -Command $command"
$process = Start-Process pwsh -ArgumentList $arguments -PassThru
Expand All @@ -86,63 +101,40 @@ The `session.json` will contain the paths of the named pipes that you will conne
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
### PowerShell Extension Terminal

![image](https://user-images.githubusercontent.com/2644648/66245084-6985da80-e6c0-11e9-9c7b-4c8476190df5.png)

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.
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`.
If you want to take advantage of the PowerShell Extension Terminal,
you must include the `-EnableConsoleRepl` switch when calling `Start-EditorServices.ps1`.

This is typically used if your client can create arbitrary terminals in the editor like below:

![Extension Terminal in vscode](https://user-images.githubusercontent.com/2644648/66245018-04ca8000-e6c0-11e9-808c-b86144149444.png)
![Extension Terminal in VS Code](https://user-images.githubusercontent.com/2644648/66245018-04ca8000-e6c0-11e9-808c-b86144149444.png)

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

#### Debugging
### 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.
It is handled within the same process as the Language Server Protocol.
This provides a more integrated experience for end users but is something to note as not many other language servers work in the same way.
If you want to take advantage of debugging,
your client must support the [Debug Adapter Protocol](https://microsoft.github.io/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:

```powershell
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
## 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
- 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.

Expand Down