"Go to Definition" should follow Import-Module references

[176coding]

Please fill in these details so that we can help you!

System Details

• Operating system name and version: win7
• VS Code version: 1.8.1
• PowerShell extension version: 0.8.0
• Output from $PSVersionTable:

Name                           Value
----                           -----
PSVersion                      5.0.10586.117
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.10586.117
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Issue Description

here we have b.psm1

function test2 () {
    Write-Host 2
}
Export-ModuleMember -Function *

and we have a.ps1 to call test2

Import-Module .\b.psm1
function test1 () {
    Write-Host 1
}
test1
test2

it can run successfully, but when I "Go to Definition" of test2 function, it not working

Attached Logs

No logs

[daviwil]

Yep, "Go to Definition" currently doesn't follow Import-Module references, that's something we need to add.

[gmckeown]

To allow for the working-directory being something other than the script path, I use the following:

# Import Include Files
$script_path = $MyInvocation.MyCommand.Path
$dir = Split-Path $script_path
import-module $dir\..\My-Functions.psm1

For me, it is preferable to keep this module with the code that depends on it rather than placing it in the module path (it keeps together all of the code I supply, and simplifies the installation for my customer). Please consider this use-case when looking at enhancing the "Go to Definition" feature.

EDIT: Should probably also note the following method for Powershell 3 and newer:

import-module $PSScriptRoot\..\My-Functions.psm1

[Jaykul]

It also needs to handle -AsCustomObject like what Pester uses:

[D0mpie]

@gmckeown:

I found out that it actually works as long as you use a hard coded path or if you use the following most preferably method.

# Import Include Files $Script_Path = $PSScriptRoot $Settings_Dir = Join-Path -Path $Global:Scriptpath -ChildPath "..\Settings" Import-Module $(Join-Path -Path $Settings_Dir -ChildPath "\My-Functions.psm1")

edit: It seems that it only works if you first run the code in debug. After that you can resolve them from ps1 to psm1 but not back. This is probably related to #499

Bug is still present in kinda way.

[D0mpie]

@gmckeown:

I found out that it actually works as long as you use a hard coded path or if you use the following most preferably method.

# Import Include Files $Script_Path = $PSScriptRoot $Settings_Dir = Join-Path -Path $Global:Scriptpath -ChildPath "..\Settings" Import-Module $(Join-Path -Path $Settings_Dir -ChildPath "\My-Functions.psm1")

edit: It seems that it only works if you first run the code in debug. After that you can resolve them from ps1 to psm1 but not back. This is probably related to #499

Bug is still present in kinda way.

I think this issue can be marked as solved. I found out that it isn't actually a bug. I did some research on the documentation and searched for "How to create a powershell module". There I found out that ..."Have a PowerShell script with a .psm1 extension. Use the same name for the script and the directory where the script is saved." as stated in the documentation.

https://docs.microsoft.com/en-us/powershell/scripting/developer/module/how-to-write-a-powershell-script-module?view=powershell-7#create-a-basic-powershell-module

Thus I saved my module in a folder called f.e. "My-Functions" containing the file My-Functions.psm1. I repeated this step for every module I previously made and altered the import-module function as follows:

Import-Module $(Join-Path -Path $Settings_Dir -ChildPath "\My-Functions\My-Functions.psm1")

Starting using this method and therefore follow the guidelines solves this problem in Visual Code.

Edit: some typos

[dezren39]

I know it's been a bit, but VSCode is becoming the defacto IDE and so I'd like to mention this issue once more. It's killing my workflow not to be able to ctrl+click or f12, I know it probably needs specific powershell love to be awesome but even if you could take add similar js/etc fuzzy plugin, and allow it to work for ps1?

In my case, specifically, it's dot-sourcing, because I really don't want to use a module in this one case. But I'd guess this oughtta be able to work anywhere. A big powershell scripty note, sometimes scripts in subdirs are actually called from repo-root, so if a go-to find fails absolute and relative from current location, going up to the nearest .git and trying from there would be... real neat fallback. :-) (edit: ugh, or sometimes the ancestor which is a child of the nearest git. like, imagine a repo root with 4 folders, a user cd's into one of the folders then executes a script that doesnt cd. or sometimes it's git clone, cd into the repo, run scripts from there without pwd.)

I'm sorry if I should make my own or just shut up am code it myself if i want it so much or something. :-)

[andyleejordan]

This works now as long as the imported module's source code exists in the workspace. That is, symbol resolution (even module-qualified) works across all workspace files. It very much won't work if the module's definition is outside the workspace, because we do not (and should not) scan code outside the workspace folder (that's both very difficult and security prone as it breaks the workspace-trust model).

[ghost]

This issue has been marked as fixed. It has been automatically closed for housekeeping purposes.