This project uses npm semver releases.
Recommended flow:
- publish prereleases with the
nextdist-tag - smoke-test the npm package directly in pi
- publish stable releases with the
latestdist-tag - commit the release on a branch, open a PR, and merge after CI passes
- tag the stable release on
mainafter merge - comment on the related PR or issue after shipping
Use next for beta/alpha/manual validation builds.
npm version prepatch --preid next --no-git-tag-version
npm test
npm run format:check
npm pack --dry-run
npm publish --tag next --access publicIf npm asks for browser or OTP auth, run the publish command manually and complete the npm prompt.
Verify the registry state:
npm view pi-commandcode-provider@next version dist-tags --jsonExpected:
nextpoints to the prerelease versionlateststill points to the previous stable version
Always test from npm, not the local checkout.
PI_SKIP_VERSION_CHECK=1 \
pi --no-extensions \
-e npm:pi-commandcode-provider@next \
--list-models commandcodeExpected:
- provider
commandcodeappears - live Command Code models are listed
Use temporary pi config and session directories so the test does not touch your real pi auth.
export PI_CC_TEST_AGENT_DIR="$(mktemp -d)"
export PI_CC_TEST_SESSION_DIR="$(mktemp -d)"
export PI_CODING_AGENT_DIR="$PI_CC_TEST_AGENT_DIR"
export PI_CODING_AGENT_SESSION_DIR="$PI_CC_TEST_SESSION_DIR"
export PI_SKIP_VERSION_CHECK=1
pi --no-extensions \
-e npm:pi-commandcode-provider@next \
--provider commandcode \
--model deepseek/deepseek-v4-flashInside pi:
/loginThen:
- choose Use a subscription
- choose Command Code
- complete the browser auth flow
- if automatic transfer fails, paste the copied Command Code API key into pi
- send this message:
Reply exactly: manual-npm-okExpected:
- login succeeds
- a Command Code credential is saved under the temporary
PI_CODING_AGENT_DIR - the model replies exactly
manual-npm-ok
Using the same exported temp variables from above:
pi --no-extensions \
-e npm:pi-commandcode-provider@next \
--no-session \
-p \
--provider commandcode \
--model deepseek/deepseek-v4-flash \
"Reply exactly: manual-npm-ok"Expected:
manual-npm-okOnly run this if these variables were created by the test above:
rm -rf "$PI_CC_TEST_AGENT_DIR" "$PI_CC_TEST_SESSION_DIR"
unset PI_CC_TEST_AGENT_DIR PI_CC_TEST_SESSION_DIR
unset PI_CODING_AGENT_DIR PI_CODING_AGENT_SESSION_DIR PI_SKIP_VERSION_CHECKAfter the next package is verified, set the intended stable version:
npm version 0.1.1 --no-git-tag-versionReplace 0.1.1 with the intended stable version.
Update CHANGELOG.md, then run checks:
npm test
npm run format:check
npm pack --dry-run
git diff --checkCommit on a release branch and open a PR:
git checkout -b release/0.1.1
git add .
git commit -m "Release 0.1.1"
git push origin release/0.1.1
gh pr create --title "chore(release): publish 0.1.1" --base mainmain is branch-protected. The release must go through a PR with passing CI.
Once CI passes, approve and merge:
gh pr review <number> --approve
gh pr merge <number> --squash --delete-branchAfter merge, pull main and tag locally:
git checkout main
git pull origin main
git tag -a v0.1.1 -m "Release 0.1.1"
git push origin v0.1.1Publish stable locally:
npm publish --tag latest --access publicPublishing is intentionally manual/local; there is no GitHub Actions publish workflow. If npm asks for browser or OTP auth, complete the npm prompt locally.
Verify npm:
npm view pi-commandcode-provider version dist-tags --json
npm view pi-commandcode-provider@0.1.1 version --jsonExpected:
latestpoints to the stable version- the stable version exists on npm
Comment on the related PR and issue after publishing and pushing:
gh pr comment <number> --body "Shipped in \`pi-commandcode-provider@0.1.1\` / tag \`v0.1.1\`."
gh issue comment <number> --body "Shipped in \`pi-commandcode-provider@0.1.1\` / tag \`v0.1.1\`."Only comment on PRs or issues actually included in the release.