Module Structure and Initialization

The glean-powershell module initializes its public and private function surfaces through a coordinated interaction between a manifest file, a loader script, and a JSON-based alias registry. The manifest defines the module metadata and explicitly lists all exported functions and aliases, serving as the static contract for the module’s interface ^{1 2 3}. The loader script dynamically discovers and dot-sources all PowerShell scripts in the Private and Public directories, ensuring that all function definitions are loaded into the session ⁴. Finally, the loader reads a generated aliases.json file to map standard PowerShell Verb-Noun commands to their corresponding dotted SDK-style aliases, exporting both sets to make them available to the user.

Module Manifest Configuration

The module manifest, Glean.psd1, acts as the primary configuration file that defines the module’s identity and export surface ¹. It specifies Glean.psm1 as the RootModule, which is the entry point for the module’s logic. The manifest explicitly lists all public functions in the FunctionsToExport array, which includes commands such as Add-GleanCollection, Connect-Glean, and Get-GleanSearch ². Additionally, it defines a comprehensive list of aliases in the AliasesToExport array, mapping these functions to dotted names that reflect the underlying API structure, such as Glean.client.collections.addItems and Glean.indexing.documents.index ³. The manifest also includes metadata such as the module version, GUID, and author information, along with private data tags like ‘REST’, ‘API’, and ‘OpenAPI’ ^{1 3}.

Module Loader and Script Discovery

The module loader, Glean.psm1, is responsible for dynamically loading the function definitions into the PowerShell session ⁴. It begins by setting $ErrorActionPreference to 'Stop' to ensure that any errors during loading halt execution. The loader then uses Get-ChildItem to recursively find all .ps1 files in the Private and Public subdirectories relative to the module’s root path ($PSScriptRoot). It combines these file lists and iterates through them, dot-sourcing each file using the . $file.FullName syntax. This approach ensures that all function definitions, whether intended for internal use (Private) or external consumption (Public), are available in the module’s scope before exports are processed.

Alias Mapping and Export

After loading the scripts, the loader handles the registration of aliases to provide compatibility with SDK-style naming conventions. It looks for a file named aliases.json in the module root directory. If this file exists, the loader reads its content, converts it from JSON, and iterates through the entries. For each entry, it uses Set-Alias to map the dotted alias name (e.g., Glean.client.chat.retrieve) to the corresponding PowerShell function name (e.g., Get-GleanChat) with a script scope and force flag. Finally, the loader calls Export-ModuleMember to explicitly export the public functions (derived from the base names of the loaded public scripts) and the registered aliases. If aliases.json is missing, it falls back to exporting only the public functions.