`using module "..\PathRelativeModule"` rejected by Intellisense

[AndrewGaspar]

I've got a project with a file hierarchy like this:

\
  \ Module
    Module.psd1
    Module.psm1
  \ Tests
    Module.Tests.ps1

At the top of Module.Tests.ps1, I have

using module "..\Module"

PowerShell itself seems to accept this statement (it loads all the module's functions and types as expected), but VS Code rejects it with the error "Could not find the module '..\Module'.". I believe this Intellisense is incorrect, but my understanding of the "using module" syntax is admittedly incomplete.

[rkeithhill]

I don't think there is such a construct as using module in PowerShell. In early v5 drops there was some support for using <namespace> but that just pulled in namespace names.

I believe what you want at the top of your test file is:

Import-Module $PSScriptRoot\..\Module\Module.psd1

Note that quotes aren't needed around path arguments unless the path contains spaces.

[AndrewGaspar]

Well, both PowerShell the shell and the VS Code extension accept the syntax. VS Code only has an issue when it can't find the module path, but that only seems to be on this relative path syntax. For example, VS Code has no problem with this fully qualified path:

using module ~\Projects\CmdUsageSyntax\CmdUsageSyntax

So the feature is at the very least build in to the version of PowerShell I'm using. Though I haven't been able to find any good documentation on it, so it may very well not be supported.

[AndrewGaspar]

For reference, PowerShell ISE is able to resolve the path correctly when opening the script. However, if I point it at a path that does not resolve to a module, it raises an error on the using statement, so it is able to correctly distinguish between relative paths that contain a module and those that do not.

[AndrewGaspar]

The bug is most likely with https://github.com/PowerShell/PowerShellEditorServices and not with the vscode extension directly.

[rkeithhill]

Looks like we got more features with the v5 using statement than I was aware of. So yeah, it appears that relative path Intellisense in the extension for VSCode is less than desirable as it is based off of the VSCode install dir. That's the bug here I think. Seems like it should be based off the open folder or the folder of the open file. Which is only a half-measure as the editor is not going to be aware of what the "current working dir" will be at runtime. This is where having a full-time REPL would be handy - relative paths would always be relative to the REPL's cwd, just like in ISE.

I was finally able to successfully import a module using a relative path:

using module ..\..\..\..\Documents\WindowsPowerShell\Modules\Await

The kicker is that the relative path is relative to where the current script resides (not the current dir). That's kind of weird and surprising. And it means that the extension needs to be aware of context i.e. using module relative paths are always relative to the current file's parent folder.

[AndrewGaspar]

Yeah, for using module specifically, the relative path is to the file not the cwd. I don't really expect that you fake relative directories generally in VS Code, since by design it's flakey. But specifically with this using module pattern, it seems like it should be a supported scenario.

It would be killer if you could auto-fill the values for $PSScriptRoot and $PSCommandPath and possibly resolve Import-Module actions that way, and thus provide IntelliSense for those modules. But I can see why that would be needlessly difficult.

[daviwil]

Thanks for the report, Andrew! As Keith identifies, this definitely seems to be an issue with the presumed cwd at the time the module resolve operation time takes place. We'll get this fixed in PowerShell Editor Services, I've filed a bug here:

PowerShell/PowerShellEditorServices#99

[TylerLeonhardt]

This was fixed in PowerShell/PowerShellEditorServices#99! I'm going to go ahead and close this now. Feel free to open a new issue if you're still having trouble.