Skip to content

using module "..\PathRelativeModule" rejected by Intellisense #64

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
AndrewGaspar opened this issue Jan 1, 2016 · 8 comments
Closed
Assignees
Labels
Issue-Bug A bug to squash.

Comments

@AndrewGaspar
Copy link

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

@rkeithhill
Copy link
Contributor

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.

@rkeithhill rkeithhill added the Issue-Bug A bug to squash. label Jan 2, 2016
@AndrewGaspar
Copy link
Author

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
Copy link
Contributor

daviwil commented Jan 2, 2016

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

@daviwil daviwil added this to the Backlog milestone Jan 10, 2016
@daviwil daviwil self-assigned this Jan 10, 2016
@TylerLeonhardt
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug A bug to squash.
Projects
None yet
Development

No branches or pull requests

4 participants