Vscode-powershell: Add a public API to enable add-on extensions

[SeeminglyScience]

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

[TylerLeonhardt]

I guess today you could throw your module into the bundled module path as a workaround.

I thought we originally had a setting that forced importing modules (via paths) into the session at start up but Omnisharp transition might have dropped that.

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

[TylerLeonhardt]

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.

Totally agree. Just wanted to unblock you at least since I'm not sure when we'll have the time to do this work. 😅 Plus, when has an implementation detail stopped you in the past 😉

[SeeminglyScience]

Totally agree. Just wanted to unblock you at least since I'm not sure when we'll have the time to do this work. 😅 Plus, when has an implementation detail stopped you in the past 😉

A whole lot more these days 😛 Now if it worked without timing issues and saved the user from having put something their profile... that'd be a different story 🙂

If we all agree this is desired then I'll implement it.

[SydneyhSmith]

Thanks @SeeminglyScience, can you clarify briefly what APIs you are planning to implement? Feel free to open a PR :smile:

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