Adapt NovaModuleTools to larger workflows and more opinionated module projects

Use the CLI or the PowerShell cmdlets directly

Every core workflow is available both as a PowerShell command or nova alias, and through the nova CLI surface. Choose the interface that fits your environment best.

Versioning behavior depends on commit history

nova bump reads Git history, not just project.json. If you want predictable release automation, keep your commit messages intentional and make sure release jobs run in repositories with full history and tags available.

Useful project.json settings

• BuildRecursiveFolders — switch recursive discovery on or off for classes, private helpers, and tests
• SetSourcePath — write source markers into the generated module to help debug parser and runtime issues
• Preamble — add module-level setup lines before generated source content
• FailOnDuplicateFunctionNames — fail the build if duplicate top-level function names are emitted
• CopyResourcesToModuleRoot — copy resources directly into the built module root instead of a nested resources/ folder

CI/CD integration

NovaModuleTools works well in build pipelines that follow the normal order:

1. build the module
2. run tests
3. publish artifacts or release

If your CI system needs standard report formats, generate JUnit and Cobertura outputs as part of the NovaModuleTools workflow rather than reinventing test-report conversion yourself.

Use local publish before repository publish

When you change manifest, resources, or module loading behavior, validate with local publish first:

nova publish -local

This helps catch packaging issues before a real repository publish or release run. In NovaModuleTools, a successful local publish also reloads the published module from the local install path so the published copy is immediately active for your next command.

Need the standard command order first? Return to Core Workflows.