NovaModuleTools
Menu Working with Modules

How-to Guides

Work with the built module instead of loose source files

NovaModuleTools is designed around the module it generates in dist/. This page explains why that matters, how to reload safely during development, how local publish changes the import story, and how to use the packaged example project as a live reference.

Why dist/ matters

NovaModuleTools does not treat your project as a pile of loose scripts. It treats it as a buildable PowerShell module project.

That means the important runtime artifact is the generated module under dist/<ProjectName>, because that is the shape Nova later tests, packages, and publishes.

Practical rule:

When you want to validate behavior, import from dist/. If you only load source files ad hoc, you can miss real packaging or manifest issues that only show up in the built output.

Import the built module

Import the built module from dist

Showing: PowerShell 

PS> Invoke-NovaBuild
PS> $project = Get-NovaProjectInfo
PS> Import-Module $project.OutputModuleDir -Force

Use this after a successful build when you want the session to use the generated module exactly as Nova produced it.

Expected result: the module imports from dist/<ProjectName>, not from your source folders.

Reload after changes

PowerShell can keep an older version of the module loaded in memory. The safe pattern is:

Reload after source changes

Showing: PowerShell 

PS> $project = Get-NovaProjectInfo
PS> Remove-Module $project.ProjectName -ErrorAction SilentlyContinue
PS> Invoke-NovaBuild
PS> Import-Module $project.OutputModuleDir -Force

Use this every time you edit functions, resources, or manifest-related settings and want to validate the current state.

If you skip the remove/rebuild/import cycle, you can think you are testing current code when you are really still using an older imported version.

Use local publish intentionally

Run a local publish

Showing: PowerShell 

PS> Publish-NovaModule -Local

Local publish is different from the normal build/import loop:

  • Nova builds the project
  • Nova runs the tests
  • Nova copies the module to the resolved local install directory
  • Nova reloads the published copy into the current PowerShell session after success

Use local publish when you want to simulate a real installed-module experience. Use the normal build/import loop when you just want fast iteration in dist/.

Do not confuse local publish with local release.

Publish-NovaModule -Local reloads the published module into the current PowerShell session after success. Invoke-NovaRelease -Local publishes locally too, but it does not import the published module afterward.

Use the packaged example as a working reference

The packaged example is more than sample content. It is a maintained project that demonstrates the Nova workflow in one place.

What the example includes

  • a full project.json with current configuration examples
  • a public function
  • a private helper
  • a resource file
  • Pester tests that validate the built module output
  • package and raw-upload examples, including Package.Types, Package.Latest, and named repositories

How to learn from it

Walk the example project end to end

Showing: PowerShell 

PS> Initialize-NovaModule -Example -Path ~/Work
PS> Set-Location ~/Work/<YourProjectName>
PS> Invoke-NovaBuild
PS> Invoke-NovaTest
PS> Test-NovaBuild
PS> $project = Get-NovaProjectInfo
PS> Import-Module $project.OutputModuleDir -Force
PS> Get-ExampleGreeting

Once you understand the example, copy the patterns you want into your own project instead of copying the whole project blindly.

See the example configuration reference