Provide an easy way to add additional module paths to PSModulePath via settings

[daviwil]

Some projects might benefit from an easy way to add paths to their PowerShell session's PSModulePath so that modules in non-standard paths are available for IntelliSense and parse-time checks.

One specific use case is developing multiple DSC resources in the same folder structure. You will get parse-time errors about missing DSC resources if your the other resources you're developing cannot be found in the PSModulePath.

It's fairly easy to change your Microsoft.VSCode_profile.ps1 to add your workspace path to $env:PSModulePath but that setting will not transfer to other developers in the project. If this was a workspace-level setting, it could be enabled for anyone who opens the code in VS Code.

[rkeithhill]

I like this idea. I imagine this would be an array and it could default to perhaps ${workspaceRoot} but it would be handy to be able to change that in a workspace settings file e.g. ${workspaceRoot}/src or ${workspaceRoot}/out. And adjusting the PSModulePath env var at the process level would be simple.

We probably need to set expectations. If your "module under development" has issues with either the PSD1 (invalid) or script files don't parse you're not likely to get the Intellisense you might be expecting. Maybe there's a way to surface such issues in a helpful (other than missing Intellisense)?

[daviwil]

Yep, exactly what I'm thinking, the setting would be a list of paths that defaults to just ${workspaceRoot}. And the nice thing is that I'm already adjusting the PSModulePath to add the "bundledModulesPath" so this would just be a generalization of what I'm doing already :)

[daviwil]

This might be a problem that can be solved using workspace profiles (https://github.com/PowerShell/vscode-powershell/issues/190).

[chriskuech]

The workspace profiles feature seems like it will be much harder to land than adding profiles, as it would automatically invoke external code on a user's system. Can someone from the extension team provide a brief summary of how they would implement adding additional module paths to PSModulePath via settings, and perhaps someone from the community (such as myself) might be able to implement it? Seems like it should be as easy as setting process.env with a value from settings before the language server is spawned.

The vscode-powershell extensions cannot currently autocomplete user-defined functions/types that aren't in the same file. This is a big feature gap compared to any other major scripting language's extension, so hopefully, this is a high-priority issue and we can fix this ASAP.

[TylerLeonhardt]

@chriskuech

The vscode-powershell extensions cannot currently autocomplete user-defined functions/types that aren't in the same file.

Autocomplete in PowerShell is based on what's available in a session. We use the same logic that hitting tab in the console uses.

Without running any files, how would I know that you want to use the functions/types defined in another file?

This is the nature of PowerShell and I'm not sure how this could ever be fixed... Unless intellisense came from looking at the AST... But then dynamic parameters, functions/types/variables added in the Integrated Console, and more wouldn't show up in intellisense.

Pros and cons...

You probably want to look at this issue though: https://github.com/PowerShell/vscode-powershell/issues/144

[TylerLeonhardt]

I really really really really wish that this issue was an easy one to fix, but $env:PSModulePath is such a messed up environment variable that I think this issue is non-trivial.

It's non-trivial because every single time a runspace is opened, the PSModulePath is "reset" thus dropping any added paths to it. I need too dig more in the code to give you a better answer on how to properly implement this feature.

[SeeminglyScience]

I need too dig more in the code to give you a better answer on how to properly implement this feature.

Pretty sure we already add the bundled modules path to PSModulePath, so it could probably be added there.

It's worth noting though, this could also cause some unintended code execution. If a workspace adds a PSModulePath with a module that exports a function for every letter (i.e. one function called a, one called b, etc) then typing anything in the editor pane will cause the psm1 to be invoked.

A lot less problematic than workspace profiles, but still something to consider.

[ilsaloving]

I am shocked that after so long, there is still no traction on this. This feature is common to every other IDE and language, and is essential for any non-trivial project. If the developers are not willing to implement this feature, is there an easy workaround?

Right now I'm setting the PSModulePath environment variable in a shell, then running code from that shell so it picks up the variable. While it works, it's very annoying.

[JustinGrote]

@ilsaloving I think the main reason this hasn't had much interest for implementation is because you can do this in your PowerShell profile, and have it apply everywhere, not just VSCode.

[ilsaloving]

But that is a different solution that solves a completely different problem. If one is working on a powershell project that is complex enough to split into multiple modules, that are specific to the app and so don't belong in the general library path, you need this functionality. That's what I'm doing right now, and it's shocking that the powershell plugin doesn't provide such basic functionality.