Add a public API to enable add-on extensions

Summary of the new feature

As a writer of a PowerShellEditorServices extension I want to enable users to install a vscode extension containing my module.

I need that extension to be able to:

1. Use the integrated console to install the module from the gallery, or provide an additional PSModulePath
2. Import the PSES extension module on vscode extension activation

I want that extension to be able to:

1. Register new requests and notifications that PSES would redirect to my module

The current install process is as follows:

1. Install the module manually from the gallery
2. Add an Import-Module statement to your profile
3. Manually add keybinds to keybinds.json (using syntax you can only determine from reading vscode-powershell’s source or a posted example)

That’s a lot to ask of folks just to try out a module.

Proposed technical implementation details (optional)

The getExtension<T> function allows vscode extensions to acquire a public API from another extension. This API would need to be surfaced by vscode-powershell internally, and optionally (though ideally) a typescript type definition would also be published to npm.

The bare minimum needed in this API would be an exported function that just imports a module from a path. Something like:

tryImportPowerShellModule(path: string) => bool

Edit: Actually a simple import function would be pretty inconsistent since it would be lost every time the console was restarted/version changed. Maybe something like:

registerPSESExtensionModule(path: string) => void;

Where vscode-powershell internally tracks registered modules and reimports them at startup.

[EklipZgit]

I believe it is very important that features like those in EditorServicesCommandSuite be addable as extensions. Some of that functionality is incredibly important to powershell development, and the vast, vast majority of users are probably completely unaware of its existence. Heck, everyone I know that uses it found out about it from twitter, or by wishing features existed and googling it and finding https://sqldbawithabeard.com/2018/03/11/easily-splatting-powershell-with-vs-code/

Ease of discovery, ease of use, reliability are all lacking here, and having better extension support (and better keymapping support, ideally) should improve discovery and ease of use. The number of users using EditorServicesCommandSuite is probably abysmally small compared to the number of users that would benefit from it.

[SeeminglyScience]

Yeah that’s something. That would at least take away the burden of updating away from the user. Not sure if that’s an implementation detail we’d want to encourage folks to depend on though.

Also that, and also the setting to force imports (if we have/had it) would have a lot of timing issues. Especially if both extensions are starting, and mine needs to update or something. Ideally it would be something the PSIC could also handle after initialization.