Skip to content

Language record

PowerShell

PowerShell is indexed as a real module system: the file is the module, its functions, classes, enums and variables are recorded, and the commands a script reaches for become edges that carry the line they are written on — with the confidence decided by the shape of the name itself.

.ps1, .psm1, .psd1 · 1 registry id · 11 of 14 relationship types

The registry row this page is generated from

Read at render time from the same family row the register reads, so nothing in this block can disagree with it.

Extensions
.ps1, .psm1, .psd1
Registry names
powershell
Recorded symbols
functions · classes · enums

Relationship types this analyzer constructs

11 of 14 constructed, read from this analyzer's source and re-derived by the languages gate. Each row below is one of the engine's types, in the engine's own order.

Relationship typeConstructed
callsconstructed by this analyzer
extendsconstructed by this analyzer
implementsconstructed by this analyzer
usesconstructed by this analyzer
importsconstructed by this analyzer
exportsconstructed by this analyzer
containsconstructed by this analyzer
referencesconstructed by this analyzer
overridesconstructed by this analyzer
instantiatesconstructed by this analyzer
decoratesruled absent
rendersruled absent
mixes_inruled absent
part_ofconstructed by this analyzer

11 constructed, 3 not constructed. All 3 absent types are recorded as ruled absent: the written reason and the corpus measurement behind each are in this family's completeness record. The register explains what each label means.

What this analyzer does not resolve

  • A .psm1 and a .ps1 of the same base name are two different modules, because the extension is part of the file's identity. The import that joins them is a file-level reference, not a merged namespace, so a function the script uses from the module is connected through the file rather than by becoming one symbol.
  • Begin, Process, End, Clean and DynamicParam are named blocks, and the grammar models each one as a command — an edge naming one would be a fabrication by construction, so all five are filtered. The same refusal list carries 44 flow and operator keywords and 17 language keywords, and a class member's set { } accessor is treated as a keyword rather than as a cmdlet.
  • PowerShell has no override keyword, so an overrides edge is a name match against the base class's declared members and is classed inferred. And the confidence of an ordinary command call is decided by its spelling: a dashed name like Get-ChildItem is 0.9, a plain one like git is 0.6 — because the shape of the name is the only signal that a bare word is a project function rather than a binary.

Every line above was written against PowerShell’s own analyzer module and is named against a construct in it, so it can be checked against the source. Nothing here is inherited from a template, or from another language’s page.

Where you meet it in a repository

Recognised by extension — .ps1, .psm1, .psd1. Everything below is about where those files actually sit in a working repository.

  • .psm1 is a module and .psd1 is its manifest, while .ps1 is a script — the distinction is carried in the file's own name rather than inferred, which matters when a repository has both spellings of the same helper.
  • Import-Module PoshRSJob is recorded as an import even though the argument is a bare module name and not a path. A path-shape requirement had been tried and silently dropped every installed module, because that is how PowerShell names them.
  • Windows administration scripts and CI step definitions are the bulk of it, and both are dominated by calls out to the machine — Get-ChildItem, Invoke-WebRequest, Start-Process — so most edges leave the graph. Thirty-nine automatic variables and thirty type accelerators are held in filter lists so that reads of them do not become undiagnosable edges.

Questions this index answers

Phrased as retrievals, because that is what an index can honestly do: it holds the symbols and the edges between them, and hands them back with the evidence attached.

  1. Which functions does this module export, and which ones does it import?
  2. What does this function call, and who calls it?
  3. Which class does this method belong to, not just the class it sits inside?
  4. Which variables does this script write that it never declares?

What the analyzer sees in code like this

A function, a class and a variable — the three shapes PowerShell records
function Get-Release {                  # bb records: function Get-Release
  param([string]$Tag)                     # bb records: variable $Tag
  Write-Output (git describe $Tag)        # a plain command name: 0.6, and no target in the repo
}

class Deployment {                        # bb records: class Deployment
  [string]$Name                           # bb records: property $Name
  Deployment([string]$n) { $this.Name = $n }   # bb records: the symbol is named "constructor"
}

Symbols are stored with the file they came from and the bytes they span, so a hit points at a line rather than at a guess. The annotations in the sample are commentary for the reader, not strings the index would store.

Languages that turn up in the same repository

Scripting & shell — the count beside each name is how many relationship types that family’s analyzer constructs.

The extensions, registry names, recorded symbols and relationship types above are the parser registry row for PowerShell, read while the page rendered — the same row the register reads, so the two surfaces cannot tell two stories. Every relationship type listed as constructed appears in src/ast/real-*, the analyzer modules bb ships. bb 0.1.0 answers from a local store over 50 languages (53 registry ids, three of them aliases). There is no benchmark on this page: every claim here is one you can go and read in the source.