Classes from NestedModules are not known to Intellisense

System Details

System Details Output

### VSCode version: 1.41.1 26076a4de974ead31f97692a0d32f90d735645c0 x64

### VSCode extensions:       
dbaeumer.vscode-eslint@2.0.15
DotJoshJohnson.xml@2.5.0     
minhthai.vscode-todo-parser@1.9.1
ms-mssql.mssql@1.8.0
ms-vscode.cpptools@0.26.3
ms-vscode.powershell@2020.1.0
ryanluker.vscode-coverage-gutters@2.4.2
streetsidesoftware.code-spell-checker@1.7.22
VisualStudioExptTeam.vscodeintellicode@1.2.4
wayou.vscode-todo-highlight@1.0.4
yzhang.markdown-all-in-one@2.7.0


### PSES version: 1.13.3.0

### PowerShell version:

Name                           Value
----                           -----
PSVersion                      6.2.4
PSEdition                      Core
GitCommitId                    6.2.4
OS                             Microsoft Windows 10.0.18362 
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Issue Description

I recently started using C# cmdlets and migrated a lot of classes from PowerShell into a shared location to be accessed between PowerShell and C# modules. After experimenting and getting assistance from the PowerShell team (see question) I found that in order to use custom classes from C# modules I am to include them in the NestedModules attribute on the manifest (psd1) file. This fixes all the issues I was having exposing the classes to the module, it does however not fix the VS Code plugin, as they are marked in red with error Unable to find type. Is this something the plugin can support?

Expected Behaviour

Classes from C# module are detected by Intellisense.

Actual Behaviour

Classes from C# module are not detected by Intellisense.

[rjmholt]

It may be the performance issues in the current stable extension release. The red squigglies you mention above are parse errors in PowerShell where its class type checking is failing because the module exporting the classes you want can’t be found. Once the module is imported that goes away, but the extension might not have made the updates to its representation of the file yet. That’s something we’ve worked to improve in the coming release.

[rjmholt]

Well that’s something of an open question. On the one hand, intellisense in PowerShell is very much machine-state-driven, so I don’t see any real way around it. On the other hand, importing modules as a side-effect of editing and getting completions is, I feel, not a great thing for an editor to do.

Similar to a lot of other scripting language extensions, we have a lot of users with different scenarios and expectations, but also unlike them, we’re also very tied to the completion/discoverability experience that PowerShell includes by default in its own engine. These two things tend to clash, since PowerShell expects a certain usage pattern and some of our users have that pattern, but others have gotten used to how other programming language experiences (editors, linters, test integrations) and our machine-dependent experience has weaknesses there.

I’d like to see the extension become more about static completions and linting, since those things don’t modify machine state, are reproduceable everywhere and scale well (so no thread management, async rabbit holes or deadlocks). But it’s unlikely we’ll be able to accomplish work like that any time soon (we’ve already invested heavily in a rearchitecture to move us off the old hand-rolled LSP infrastructure that the stable extension currently uses). Meaning you’ll still need to load modules to get intellisense on them, and intellisense will still load modules.

But it all works (save for the odd edge case), has gotten faster (and is still improving – next step is to make PSScriptAnalyzer substantially faster) and I think compares favourably with something like the ISE. I’d just like to see it look like the Python or the JS editing experience (which, once upon a time, I had set up in vim with full completions, help and linting, all pretty maintainably, on a small, unbeefy laptop, with no complaints).