npm Publishing¶
Nuzo's host plugins resolve the shared runtime from:
The MCP package depends on:
The CLI package also depends on:
Core, CLI, and MCP packages use the same version and must be released together.
Scope Ownership¶
The preferred public scope is @nuzo.
An npm organization named nuzo must exist and the release maintainer must
have publishing access before the first release. An E404 from npm view
only confirms that a package is not currently public; it does not prove that
the organization scope is available or owned by the project.
Confirm interactively:
Do not change public package names until the scope decision is durable. Package names become part of the public API after release.
Source Protection¶
The source workspace packages remain:
Do not run npm publish from packages/core, packages/cli, or
packages/mcp-server.
Generate publish candidates instead:
This creates ignored staging directories and tarballs under:
The staging process:
- removes
privateonly from generated package metadata; - removes development scripts and dependencies;
- pins the CLI and MCP server to the exact core version;
- copies runtime output, README, and Apache-2.0 license;
- rejects tests, source files, databases, exports, secrets, and environment files.
Validation¶
Run:
The validation:
- rebuilds from clean
distdirectories; - creates all three tarballs with
npm pack; - installs all tarballs into a temporary project;
- confirms package versions match;
- runs the installed
nuzobinary through init, remember, recall, and doctor; - starts the installed
nuzo-mcp-serverbinary against a temporary store.
The command does not publish anything.
First Publication¶
Do not publish version 0.0.0. Follow the release checklist and move all Nuzo
packages and plugin manifests to the first release version together.
Publish in dependency order:
cd build/npm/packages/memory-core
npm publish --access public
cd ../memory-cli
npm publish --access public
cd ../mcp-server
npm publish --access public
Verify before distributing host plugins:
npm view @nuzo/memory-core@<version> version
npm view @nuzo/memory-cli@<version> version
npm view @nuzo/mcp-server@<version> version
npx --yes @nuzo/memory-cli@<version> memory doctor
npx --yes @nuzo/mcp-server@<version>
The first publication should be performed by an authenticated maintainer with 2FA. After all packages exist, configure npm trusted publishing for the release workflow so routine releases use GitHub Actions OIDC instead of a long-lived token.
Credentials¶
Never commit:
.npmrccontaining credentials;NODE_AUTH_TOKEN;- npm access tokens;
- 2FA recovery codes;
- npm debug logs containing authentication context.
If a token is used temporarily:
- create a granular token with the narrowest package access and expiration;
- store it only in the approved secret store;
- revoke it immediately if exposed or no longer required;
- remove local credential files after use.
Prefer trusted publishing once the initial packages and publisher relationship exist.
Recovery¶
If publication fails:
- Stop before retrying with broader credentials.
- Check
npm whoamiand organization membership. - Confirm the target version does not already exist.
- Re-run
npm run validate:npm. - Inspect the generated staging package, not the source workspace package.
- If credentials may have leaked, revoke them before further work.
Never delete or rewrite a published version to repair a failed release. Fix the problem and publish a new SemVer version.