Skip to content

PowerShell plugin: Install-Module PowerShellEditorServices instructions are incorrect — module is not published to PSGallery #67

@tablackburn

Description

@tablackburn

Summary

The powershell-editor-services plugin's launcher assumes PowerShellEditorServices (PSES) is installable via Install-Module and discoverable on $env:PSModulePath, but PSES is not published to the PowerShell Gallery. Following the plugin's own error message leaves users with a non-working install.

Repro

  1. Install pwsh 7+ (I'm on 7.6.0).
  2. Enable the powershell-editor-services plugin per the README.
  3. Run the install command the plugin tells you to run:
    Install-Module PowerShellEditorServices -Scope CurrentUser
  4. Result:
    Install-Package: No match was found for the specified search criteria and module name 'PowerShellEditorServices'.
    

Find-Module PowerShellEditorServices also returns the same error, and Install-PSResource PowerShellEditorServices fails identically. PSGallery is registered and trusted:

Name        InstallationPolicy   SourceLocation
----        ------------------   --------------
PSGallery   Trusted              https://www.powershellgallery.com/api/v2

Verification that PSES isn't on PSGallery:

Root cause

Two mismatches with upstream:

1. Distribution model. PSES upstream (PowerShell/PowerShellEditorServices) does not ship as a standard PSGallery module. Its README only documents the bundle model: download PowerShellEditorServices.zip from GitHub Releases, extract anywhere, and launch via Start-EditorServices.ps1 by absolute path. All reference clients (VS Code, Vim, IntelliJ) consume it that way.

2. Launcher shape. The plugin's .lsp.json currently does:

$module = Get-Module -ListAvailable PowerShellEditorServices | Sort-Object Version -Descending | Select-Object -First 1
if (-not $module) { throw 'PowerShellEditorServices is not installed. Run: Install-Module -Name PowerShellEditorServices -Scope CurrentUser' }
Import-Module $module.Path
Start-EditorServices -HostName 'Claude Code' ... -Stdio -BundledModulesPath (Split-Path $module.Path) ...

This requires PSES to live under $env:PSModulePath, which only happens if the user manually extracts the release zip into a Modules folder — a layout upstream doesn't document or test.

Proposed fix

Align the launcher with PSES's documented invocation: accept a bundle path and call Start-EditorServices.ps1 by path, the same way VS Code, Vim, and IntelliJ do. Something like:

{
  "powershell": {
    "command": "pwsh",
    "args": [
      "-NoLogo",
      "-NoProfile",
      "-File", "${PSES_BUNDLE_PATH}/PowerShellEditorServices/Start-EditorServices.ps1",
      "-Stdio",
      "-BundledModulesPath", "${PSES_BUNDLE_PATH}",
      "-HostName", "Claude Code",
      "-HostProfileId", "ClaudeCode",
      "-HostVersion", "1.0.0",
      "-LogPath", "...",
      "-LogLevel", "None"
    ]
  }
}

…with README instructions that tell users to:

  1. Download PowerShellEditorServices.zip from https://github.com/PowerShell/PowerShellEditorServices/releases/latest
  2. Extract it to a stable location
  3. Set PSES_BUNDLE_PATH (or equivalent plugin setting) to that directory

If the plugin config can't template env vars, an alternative is a one-line setting in the plugin config (e.g. bundlePath) that the launcher reads.

Minimum acceptable fix

If a full rewrite isn't desired, at minimum update the thrown error message so users aren't sent to a nonexistent PSGallery package. Pointing them at the GitHub Releases page and explaining the bundle-copy step would prevent the dead end.

Environment

  • Claude Code: 2.1.5x
  • OS: Windows 11
  • pwsh: 7.6.0
  • PSGallery: registered, trusted
  • PowerShellGet: 2.2.5 / PackageManagement: 1.4.8.1

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions