Vscode-powershell: First-class dependency modules (PSScriptAnalyzer, Plaster) should not be bundled with the extension

Created on 6 Dec 2016  路  9Comments  路  Source: PowerShell/vscode-powershell

Currently we bundle the PScriptAnalyzer module with the PowerShell extension for the sake of convenience. Instead of this, we should either use the user's installed, compatible version of the modules or prompt them to install the dependency modules. We can take care of the entire module installation experience.

Eventually we may consider removing the PowerShellEditorServices module from being bundled with the extension but we'll need to find a very smooth and convenient way for installing the module so that the user has a friction-free "getting started" experience as they do today.

Issue-Enhancement

Most helpful comment

Gonna close this since I don't think we wanna go in this direction

All 9 comments

@kapilmb will try to get this started for the PSScriptAnalyzer integration for 0.9.0.

It would be really great if VS Code could use the user installed module for PSScriptAnalyzer as requested here. The built-in version is usually a little bit outdated.

Is there a workaround in the meantime? To have VS Code use a specific module instead?

Thank you for having another look at this.

@DarkLite1 If you have a newer version in your $env:PSModulePath that'll be used instead (If it ever doesn't do that, that's probably a bug).

If we stop bundling modules like PSSA, then we'll have to prompt the user to update every time we take a dependency on a newer version. Ultimately I think that would end up causing more harm then good. As long as we continue to use newer versions installed by the user, I think this issue should be closed.

I hear you but when I run Get_Module, after hitting SHIFT + ALT + F the module is not loaded. Is there a way that I can check what version of PSSA is running?

Yeah, the module runs in a different runspace. Since it's a binary module though, you can see which one is loaded with this:

[Microsoft.Windows.PowerShell.ScriptAnalyzer.Phi].Assembly.Location

I don't think this issue is a good idea.

We should always ship a version of PSSA because of the concerns @SeeminglyScience mentioned.

As for Plaster... It's a relatively small package and people depend on it.

Adding this barrier for both us and the user is just over complicating PSES.

This would apply to PowerShellEditorServices.VSCode only IMO and I think the work involved is just not worth it.

For me personally it's sufficient if vscode picks up the latest and greatest version available in my module path. According to the line provided by @SeeminglyScience this is already the case in vscode-insders.

So for me this is enough. Thanks for the help guys 馃憤

Gonna close this since I don't think we wanna go in this direction

Was this page helpful?
0 / 5 - 0 ratings