A mechanism to allow types in other files to be seen by VS Code

[nathan-alden-hp]

Summary of the new feature/enhancement

In the programming world, developers are encouraged to follow a "one type per file" rule. I am trying to apply this rule to classes in PowerShell. Unfortunately, I can't find a way to allow my editor (VS Code in my case) to "see" types in other files. Consider this trivial case where I have a module consisting of two classes:

Class1.ps1

class Class1 {
    [void]Method() {}
}

Class2.ps1

class Class2 {
    Class2() {
        $c = [Class1]::new() # VS Code reports "unable to find type [Class1]"
        $c. # Typing the dot does not display any members
    }
}

I know why the warning occurs, but this effectively forces me to declare all my types in a single file in order to benefit from VS Code's PowerShell analyzer. That means with a big enough number of types, the single file can easy reach thousands of lines, making it harder to maintain and making it harder to tell via Git diffs what types were changed.

Is there a way around this problem?

Proposed technical implementation details (optional)

I'm not sure what can be done to improve the developer experience, but as it stands now this is preventing me from using classes to their full extent in my more complex PowerShell modules. I know I could always create a full-blown C# project, but that introduces build pipeline and CI dependencies I'm trying to avoid. It also means developers who work on my module need to be more aware of .NET tools like Visual Studio than they otherwise would need to be.

Some kind of special comment used by the analyzer to temporarily import other files for the purposes of parsing, perhaps?

#analyze Class1.ps1

What is the latest version of PSScriptAnalyzer at the point of writing

Not sure, but I'm using the 2020.6.0 version of the VS Code PowerShell extension.

[bergmeister]

The vs code PowerShell extension is here:
https://github.com/PowerShell/vscode-powershell
There is nothing automatic right now but using the integrated terminal of the ps extension you can manually load the types there and the editor will then recognise them

[SydneyhSmith]

Thanks @nathan-alden-hp one question, I notice you are using using module in your screenshot, what module are you referencing there? If you change your ps1 files to psm1 files and then add using module .\Class1.psm1 for this should resolve the warning

[nathan-alden-hp]

Thank you both for the replies. However, the reason I created this issue is because of the level of inconvenience I have to incur to do the right thing (one type per file). Manually loading types and treating classes as individual modules with using module are not acceptable. In my opinion, either the analyzer or the extension (or both working together) should provide a capability to stitch together the required types from not only modules (using module) but also loose files without requiring special scripts to remove temporary using module statements.

In particular, the using module method has the following drawbacks:

• When preparing the module for distribution, I have to remove the temporary using module statements with a script.
• VS Code is able to detect the type, but not its members (see screenshot)

I'm going to submit this issue in the vscode-powershell repo to see what they have to say.