Skip to content

Classes from NestedModules are not known to Intellisense #2451

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
LethiferousMoose opened this issue Jan 31, 2020 · 6 comments
Closed

Classes from NestedModules are not known to Intellisense #2451

LethiferousMoose opened this issue Jan 31, 2020 · 6 comments

Comments

@LethiferousMoose
Copy link

System Details

System Details Output

### VSCode version: 1.41.1 26076a4de974ead31f97692a0d32f90d735645c0 x64

### VSCode extensions:       
[email protected]
[email protected]     
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]


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

@ghost ghost added the Needs: Triage Maintainer attention needed! label Jan 31, 2020
@LethiferousMoose
Copy link
Author

False alarm, I made some edits to the file and now everything works. Very strange.

@rjmholt
Copy link
Contributor

rjmholt commented Jan 31, 2020

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.

@LethiferousMoose
Copy link
Author

Thanks @rjmholt I was actually just coming back to ask a follow-up question, but that seems to answer it. It does happen consistently when first launching, then as soon as you make a file change it corrects itself, my guess if you are right and the modules aren't yet loaded on open.

@rjmholt
Copy link
Contributor

rjmholt commented Jan 31, 2020

It may actually be working as a side-effect of unintended module loading. See #715.

@LethiferousMoose
Copy link
Author

@rjmholt What is the expected outcome of #715? How will Intellisense work if it ends up not importing dependent modules?

@rjmholt
Copy link
Contributor

rjmholt commented Jan 31, 2020

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

@SydneyhSmith SydneyhSmith removed the Needs: Triage Maintainer attention needed! label Feb 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants