Publish a package¶

nodos publish uploads a module to the Nodos Store so other people — or other machines — can nodos install it.

1. Authenticate¶

nodos auth login

This runs a device flow: it prints a code, you approve it in a browser. The token persists until nodos auth logout.

2. Check what will be uploaded¶

Run a dry run first. Always.

nodos publish --path ./Module/mycorp.myplugin --dry-run --verbose

Without a .nospub file, every file under the path is included — build intermediates, local config, .env files, whatever happens to be sitting there. The dry run is how you find that out before it is public rather than after.

3. Control the file list¶

Add a .nospub at the package root listing glob patterns to include:

.nospub

{
    "globs": [
        "/Binaries/**/*.{dll,so,dylib}",
        "/Nodes/**",
        "/Include/**",
        "/Types/**",
        "/Config/**",
        "/*.nosplugin"
    ]
}

Paths are rooted at the package directory. Only matching files are published.

4. Publish¶

nodos publish --path ./Module/mycorp.myplugin

Name, version and type are read from the manifest. Supply them explicitly only when publishing something with no manifest — a generic package, say:

nodos publish --path ./artifacts --name mycorp.assets --version 1.0.0 --type generic

Valid types are plugin, subsystem, nodos, engine and generic.

Visibility¶

New packages are public by default. To restrict the first publish to your namespace and accounts you explicitly grant:

nodos publish --visibility private

Note

--visibility only applies when the package is created. For a package that already exists on the store the flag is ignored — change visibility from the Nodos Store dashboard instead.

Platforms¶

A published version is per-platform. The current platform is used unless you say otherwise:

nodos publish --target-platform x86_64-windows

Publish once per platform you support, using the same version each time.

Changelogs¶

Release notes are resolved in this order:

--changelog "..." if you pass it.
A CHANGELOG.md in the package directory.
A changelog generated by the store from the artifact diff.

Generation needs git history, so nosman fetches tags and unshallows the repository first. Under a CI checkout that is shallow by default this matters; if you have a reason to skip it, pass --no-fetch-tags and accept the reduced changelog.

Git tags¶

A successful publish creates and pushes a git tag:

release-<name>-<version>-<target>

To opt out:

--no-push-tag — create the tag locally, do not push.
--no-tag — do not create one at all.

Publishing a whole repository¶

For a monorepo of modules:

nodos publish-batch

This publishes all — or only changed — packages under the git repository, which is what you want in a CI job triggered on merge.

Unpublishing¶

nodos unpublish

Treat this as a break-glass tool. Anyone who already depends on that version will stop being able to resolve it. Publishing a superseding version is almost always the better answer.

Before you publish¶

Version bumped in the manifest. On an API break, bump major — see Versioning and SDK lines.
.nospub present and --dry-run output checked.
No secrets, credentials or local paths in the file list.
sdk_version in the manifest matches the SDK line you actually built against.
Dependencies declared with the minimum versions you actually require.
Built and loaded cleanly from a fresh workspace.