Reference

Use the right command the first time

NovaModuleTools exposes every major workflow as a PowerShell cmdlet and, in most cases, a matching nova command. Use this page to choose the right entrypoint, understand the key parameters, and jump to deeper task guides.

Choose cmdlet vs CLI

Use PowerShell cmdlets when you want scriptable functions, structured output, or direct parameter names. Use nova when you want a command-line experience that feels consistent across day-to-day workflows.

Use case Best entrypoint Why
Interactive local development inside pwsh nova alias or cmdlets After you import the module, both are available in the same session.
Shell use on macOS/Linux nova launcher Install it once with Install-NovaCli so you can run Nova from zsh or bash.
Reusable scripts and automation PowerShell cmdlets Cmdlets are easier to compose and return richer objects in PowerShell.
Quick manual tasks nova The command names mirror the main workflow: init → build → test → package → deploy → publish → release.

Important: nova inside PowerShell is an alias for Invoke-NovaCli. On macOS/Linux you can also install the standalone launcher with Install-NovaCli.

Project and scaffold commands

Initialize-NovaModule / nova init

Create a new project scaffold. Use -Example when you want a complete working sample instead of the minimal starter layout.

  • Best for: creating a new project
  • Key parameters: -Path, -Example
  • Important CLI caveat: use nova init -Path ~/Work; positional paths are intentionally rejected
Initialize-NovaModule -Path ~/Work
nova init -Example -Path ~/Work

See the scaffold tutorial

Get-NovaProjectInfo / nova info

Read the current project.json and return resolved project metadata, defaults, and important paths such as dist/ and tests/.

  • Best for: scripts, troubleshooting, and understanding resolved paths
  • Key parameters: -Path, -Version
  • Output: a project object, or just the version string when you use -Version
Get-NovaProjectInfo
Get-NovaProjectInfo -Version
nova info

See project.json behavior

Build and test commands

Invoke-NovaBuild / nova build

Build the current project into dist/<ProjectName>, generate the manifest, generate external help, and copy project resources.

  • Best for: producing the real module you intend to import, test, package, or publish
  • Key switches: -WhatIf, -Confirm
  • Notable behavior: respects SetSourcePath, Preamble, and duplicate function validation
Invoke-NovaBuild
nova build -WhatIf

See the build workflow

Test-NovaBuild / nova test

Run Pester against the current project configuration and write test results to artifacts/TestResults.xml.

  • Best for: validating the project test suite from the normal Nova workflow
  • Key parameters: -TagFilter, -ExcludeTagFilter, -OutputVerbosity, -OutputRenderMode
  • Notable behavior: uses BuildRecursiveFolders to decide nested test discovery
Test-NovaBuild -TagFilter unit,fast
nova test -WhatIf

See the test workflow

Packaging and delivery commands

New-NovaModulePackage / nova package

Build, test, and package the module. By default it creates a .nupkg in artifacts/packages/. Use Package.Types and related settings to customize the output.

  • Best for: creating package artifacts from the built module output
  • Key settings: Package.Types, Package.Latest, Package.OutputDirectory
  • Output: one object per generated artifact
New-NovaModulePackage
nova package

See packaging details

Deploy-NovaPackage / nova deploy

Upload existing package artifacts to a raw HTTP endpoint. This command does not build, test, or package anything first.

  • Best for: raw package repositories such as Nexus or Artifactory style endpoints
  • Key parameters: -PackagePath, -PackageType, -Url, -Repository, dynamic parameters for headers and auth
  • Notable behavior: uploads every matching versioned and latest artifact it resolves
Deploy-NovaPackage -Repository LocalNexus
nova deploy -url https://packages.example/raw/ -token $env:NOVA_PACKAGE_TOKEN

See raw upload details

Publish-NovaModule / nova publish

Build, test, and publish the module either locally or to a registered PowerShell repository.

  • Best for: PowerShell repository publishing or validating a local publish/install cycle
  • Key parameters: -Local, -Repository, -ModuleDirectoryPath, -ApiKey
  • Notable behavior: local publish reloads the published module into the current PowerShell session
Publish-NovaModule -Local
nova publish -repository PSGallery -apikey $env:PSGALLERY_API

See publish details

Invoke-NovaRelease / nova release

Run the full release flow: build, test, bump version, build again, and then publish.

  • Best for: an orchestrated release command when you want one workflow instead of separate steps
  • Key parameters: -PublishOption, -Path
  • Important difference: local release does not reload the published module into the session after publishing
Invoke-NovaRelease -PublishOption @{ Local = $true }
nova release -repository PSGallery -apikey $env:PSGALLERY_API

See release details

Versioning and release commands

Update-NovaModuleVersion / nova bump

Read Git history, choose the semantic version label, and update project.json.

  • Best for: Git-driven semantic version updates
  • Key parameter: -Path
  • Notable behavior: falls back to a patch bump when the folder is not a Git repository, but throws when the repository exists and has no commits yet
Update-NovaModuleVersion -WhatIf
nova bump -Confirm

See versioning rules

nova version, nova version -Installed, and nova --version

These commands answer different questions, so use the one that matches your intent.

  • nova version: current project version from project.json
  • nova version -Installed: locally installed version of the current project/module
  • nova --version: installed NovaModuleTools version
nova version
nova version -Installed
nova --version

See version view differences

Update and preference commands

Update-NovaModuleTool / Update-NovaModuleTools / nova update

Self-update the installed NovaModuleTools module by using the stored prerelease preference.

  • Best for: keeping NovaModuleTools itself up to date
  • Key behavior: stable updates are always eligible; prerelease targets depend on your stored preference and require explicit confirmation
  • Output: plan/result information, plus a release notes link after success
Update-NovaModuleTool
nova update

See self-update behavior

Get-NovaUpdateNotificationPreference, Set-NovaUpdateNotificationPreference, and nova notification

Inspect or change whether prerelease self-updates are eligible.

  • Best for: keeping production systems on stable releases, or opting into prerelease self-update targets on purpose
  • Key commands: nova notification, nova notification -disable, nova notification -enable
  • Output: a preference object with the stored state and settings path
Get-NovaUpdateNotificationPreference
Set-NovaUpdateNotificationPreference -DisablePrereleaseNotifications
nova notification -enable

See update preference guidance