Home > database >  How to make parameter name suggestions work?
How to make parameter name suggestions work?

Time:08-30

I'm trying to create a powershell module to store some reusable utility functions. I created script module PsUtils.psm1 and script module manifest PsUtils.psd1 (used these enter image description here

When I hover cursor over the function I only get this:

enter image description here

PsUtils.psm1

function Get-Filelist {
    Param(
        [Parameter(Mandatory=$true)]
        [string[]]
        $DirectoryPath
    )
    Write-Host "DIR PATH: $DirectoryPath"
}

PsUtils.psd1 (excerpt)

...
FunctionsToExport = '*'

I have Powershell extension installed. Do I need to install anything else to make the suggestions work? What am I missing?

CodePudding user response:

  • Generally speaking, only auto-loading modules - i.e., those in one of the directories listed in environment variable $env:PSModulePath - are automatically discovered.

  • As of version v2022.7.2 of the PowerShell extension, the underlying PowerShell editor services make no attempt to infer from the current source-code file what modules in nonstandard directories are being imported via source code in that file, whether via Import-Module or using module

    • Doing so would be the prerequisite for discovering the commands exported by the modules being imported.

    • Doing so robustly sounds virtually impossible to do with the static analysis that the editor services are limited to performing, although it could work in simple cases; if I were to guess, such a feature request wouldn't be entertained, but you can always ask.


Workarounds:

Once you have imported a given module from a nonstandard location into the current session - either manually via the PIC (PowerShell Integrated Console) or by running your script (assuming the Import-Module call succeeds), the editor will provide IntelliSense for its exported commands from that point on, so your options are (use one of them):

  • Run your script in the debugger at least once before you start editing. You can place a breakpoint right after the Import-Module call and abort the run afterwards - the only prerequisite is that the file must be syntactically valid.

  • Run your Import-Module command manually in the PIC, replacing $PSScriptRoot with your script file's directory path.

    • Note: It is tempting to place the cursor on the Import-Module line in the script in order to use F8 to run just this statement, but, as of v2022.7.2, this won't work in your case, because $PSScriptRoot is only valid in the context of running an entire script.

    • GitHub issue #633 suggests adding special support for $PSScriptRoot; while the proposal has been green-lighted, no one has stepped up to implement it since.

  • (Temporarily) modify the $env:PSModulePath variable to include the path of your script file's directory.

    • The most convenient way to do that is via the $PROFILE file that is specific to the PowerShell extension, which you can open for editing with psedit $PROFILE from the PIC.

      • Note: Make sure that profile loading is enabled in the PowerShell extension's settings.
    • E.g., if your directory path is /path/to/my/module, add the following:

      $env:PSModulePath ="$([IO.Path]::PathSeparator)/path/to/my/module"
      
    • The caveat is that all scripts / code that is run in the PIC will see this updated $env:PSModulePath value, so at least hypothetically other code could end up mistakenly importing your module instead of one expected to be in the standard locations.

    • Note that GitHub issue #880 is an (old) proposal to allow specifying $env:PSModulePath entries as part of the PowerShell extension settings instead.


On a somewhat related note:

  • Even when a module is auto-discovered / has been imported, IntelliSense only covers its exported commands, whereas while you're developing that module you'd also like to see its private commands. Overcoming this limitation is the subject of GitHub issue #104.
  • Related