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 (#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: #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.