In PowerShell, what is the difference between a .psm1 script module file and a .psd1 module manifest, and what does adding a manifest give you?

## What a "module" is A PowerShell module is a unit of packaging: a folder whose name matches the module name, placed somewhere on `PSModulePath`, containing the code and (usually) the metadata that describes it. Importing a module adds its functions, cmdlets, aliases and variables into your session. There are three kinds you meet in practice — script modules, binary modules, and manifest modules — and the last of those is the source of most of the confusion in this question. ## The script module: .psm1 A script module is a file with a `.psm1` extension. Its contents are ordinary PowerShell — the extension is what tells PowerShell to treat it as a module rather than a script to run once. When the module is imported, the whole file is executed in its own module scope, which is why the functions it defines become available while its internal helper variables do not leak into your session. ```powershell # Tools/Tools.psm1 function Get-DiskFree { Get-PSDrive -PSProvider FileSystem | Select-Object Name, Used, Free } Export-ModuleMember -Function Get-DiskFree ``` By default a `.psm1` exports all of its functions. The moment you call `Export-ModuleMember` even once, only what you name is exported — that is how you keep private helpers private. A `.psm1` on its own is a complete, importable module. Nothing about a manifest is mandatory for it to work. ## The manifest: .psd1 A manifest is a file with a `.psd1` extension whose entire content is a single PowerShell hashtable literal. It contains no executable logic — PowerShell reads it in a restricted way, precisely so that discovering a module does not mean running its code. ```powershell @{ RootModule = 'Tools.psm1' ModuleVersion = '1.4.0' GUID = 'd0e9a1b2-3c4d-5e6f-7a8b-9c0d1e2f3a4b' Author = 'Platform Team' Description = 'Small disk and inventory helpers.' PowerShellVersion = '5.1' RequiredModules = @('Microsoft.PowerShell.Management') FunctionsToExport = @('Get-DiskFree') CmdletsToExport = @() AliasesToExport = @() VariablesToExport = @() PrivateData = @{ PSData = @{ Tags = @('disk','inventory') } } } ``` You do not have to type that by hand: `New-ModuleManifest -Path .\Tools\Tools.psd1 -RootModule 'Tools.psm1' -ModuleVersion '1.4.0'` writes a fully commented template, and `Test-ModuleManifest .\Tools\Tools.psd1` parses it and reports what it would export. `RootModule` is the link between the two files: it names the code that is loaded when the module is imported. A manifest with no `RootModule` at all is legal — that is a **manifest module**, typically used as an umbrella that pulls in several nested modules via `NestedModules`. ## What the manifest actually buys you - **A version.** `ModuleVersion` is what lets several versions of the same module sit side by side and lets a script ask for one specifically. - **Identity.** `GUID` identifies the module across renames and across repositories. - **Declared dependencies.** `RequiredModules` and `PowerShellVersion` fail the import early and loudly instead of failing deep inside a function. - **An explicit public surface.** The export lists are your API contract; everything not listed is an implementation detail you are free to change. - **Publishability.** `Publish-Module` requires a manifest, and the gallery page is rendered from `PrivateData.PSData` (`Tags`, `LicenseUri`, `ProjectUri`, `ReleaseNotes`). ## Exports are an intersection, not an override A classic beginner bug: the `.psm1` exports `Get-DiskFree`, the manifest lists something else or an empty array, and the command "disappears". The effective export set is the intersection of what the code exports and what the manifest lists. Listing a function in `FunctionsToExport` cannot resurrect one the `.psm1` withheld, and exporting from the `.psm1` cannot bypass a manifest that does not list it. The other habit worth naming is leaving `FunctionsToExport = '*'`. It works, but PowerShell then cannot know the module's commands without loading it, which slows down command discovery in every session. Enumerate them explicitly. ## Binary modules, briefly A binary module is a compiled .NET assembly (`.dll`) whose classes derive from `Cmdlet` or `PSCmdlet`. You choose one when you need real .NET performance, tighter parameter binding, or code you would rather not ship as readable text. Its `RootModule` points at the `.dll`, and it uses `CmdletsToExport` rather than `FunctionsToExport`. Most team automation is a script module; binary modules are the exception, not the norm. ## What an interviewer is listening for That you know the manifest is data and the `.psm1` is code; that a manifest is optional to import but effectively mandatory to distribute; and that you can name three or four manifest keys and say what each one is for.