0.1.0 is unpublished on both npm and PyPI, blocking retirement of the 322-line auth-client fork

[dmccoystephenson]

The state

Neither distribution of this repository exists on any registry. Verified 2026-09-06:

Check	Command / URL	Observed
npm	https://registry.npmjs.org/@kingdom-community%2fsession-client	HTTP 404
PyPI	https://pypi.org/pypi/session-client/json	HTTP 404
Releases	gh release list -R kingdom-community/session-client	empty
Tags	gh api repos/kingdom-community/session-client/tags	0
npm release runs	gh run list -R kingdom-community/session-client --workflow release-npm.yml	zero runs, ever
PyPI release runs	gh run list -R kingdom-community/session-client --workflow release-pypi.yml	zero runs, ever
js/package.json:3		0.1.0
python/pyproject.toml:7		0.1.0

Both workflows are workflow_dispatch-only by design. release-npm.yml:3-6:

# workflow_dispatch ONLY. Releases are a deliberate act: nothing here fires on a
# push, a tag or a merge, so an accidental commit can never publish a version.
# The version published is whatever is in js/package.json on the chosen ref;
# bump it in a pull request first.

The policy is sound. What is recorded here is that the deliberate act has never been taken for either half.

CI on main is green (ci.yml, run 33594101670, 2c8300a), and unusually for this set it gates both halves — a JavaScript matrix (typecheck, test, build) and a Python matrix (pip install ., unittest discover). js/README.md:14 instructs npm install @kingdom-community/session-client and python/README.md:14 instructs pip install session-client; both commands 404 today.

What is waiting on it

The private site this library was extracted from still carries the fork. Measured 2026-09-06:

Forked file	Lines
services/userAuthService.ts	213
services/sessionService.ts	109
Total	322

An org-wide code search for "@kingdom-community/" in:file filename:package.json returns 0 results. Nothing depends on this package, because nothing can.

The stake here is higher than the line count suggests: those two files are that site's entire authentication path against its upstream auth service. A fork of an auth client that cannot receive fixes is the fork that matters most to retire, and it is the one that has been waiting longest — main here has not moved since 2026-09-02, while the JavaScript library sits finished and unreachable.

What must happen

1. Confirm the publish credentials exist — they are two different mechanisms.
   • npm. release-npm.yml:55 reads secrets.NPM_TOKEN. gh api repos/kingdom-community/session-client/actions/secrets reports total_count: 0, so nothing is set at repository level — but an organisation-level secret would satisfy it, and organisation secrets could not be read from here: gh api orgs/kingdom-community/actions/secrets returned HTTP 403 ("You must be an org admin or have the actions secrets fine-grained permission"). Unverified, not a confirmed gap.
   • PyPI. release-pypi.yml uses trusted publishing (OIDC) via pypa/gh-action-pypi-publish, with the publish job pinned to environment: pypi. Its header at lines 8-11 states the prerequisite plainly: "Configure the publisher on PyPI for this repository and the pypi environment before the first run, or set PYPI_API_TOKEN and swap the password input back in." One observation bears on that: gh api repos/kingdom-community/session-client/environments returns {"total_count": 0, "environments": []} — no pypi environment currently exists in this repository. GitHub will materialise a referenced environment at run time, so this is not necessarily fatal, but a PyPI trusted publisher must be registered against the exact repository, workflow filename and environment name before the job can authenticate. Whether that registration has been done on PyPI could not be checked from here and needs confirmation.
2. Decide whether 0.1.0 is the right first version, and whether the two halves must share it. Both manifests say 0.1.0 today. Publishing them together keeps that alignment meaningful; publishing only one starts a divergence that will need a policy sooner or later.
3. Fire the workflows from main. release-npm.yml takes a dry_run input defaulting to true, so the first invocation packs and checks without publishing — that default should be exercised before it is overridden. release-pypi.yml has the same dry_run default, building and running twine check without uploading.
4. Unblock the consumer issue so the forked services/userAuthService.ts and services/sessionService.ts can be replaced with the npm dependency.

Open questions

• Should the Python distribution be published at all yet? No consumer for it has been found anywhere in the organisations surveyed — every identified caller of this library is TypeScript, and the fork waiting on it is two .ts files. The Python half is a maintained, CI-gated, test-covered package with, as far as could be established, nobody to install it. Two positions are defensible: publish it alongside the npm half so the name session-client on PyPI is claimed before someone else takes it and so parity is never a special case; or hold it until something actually needs it, and avoid committing to a public API and a support burden for zero users. The name-squatting argument is not trivial — session-client is an unscoped, generic PyPI name with no namespace protecting it, unlike the npm side which is safe inside the @kingdom-community scope. This search was incomplete: the org-scoped code searches for Python consumers hit GitHub's search rate limit partway through, so two of the four organisations were not fully covered. The absence of a Python consumer should be treated as probable, not proven.
• Is green CI sufficient to release? For the JavaScript half, dry_run: true makes this cheap to answer — run it, read the npm pack --dry-run output, and confirm the files/main/types shape before flipping the flag. That option is worth using; an npm version cannot be re-published once taken.

---

This issue records a release-blocker found while surveying the six extracted libraries; no code was changed and no workflow was fired.

---

drafted by Claude on behalf of Daniel Stephenson

[dmccoystephenson]

Update — the credential question is now settled, and the answer is that it does not exist.

This issue recorded the publish credential as needing confirmation rather than as a known gap, because organisation secrets cannot be listed without admin:org. A release dispatch has since resolved it.

kingdom-community/minecraft-server-ping run 34064655610 was dispatched on 2026-09-06. Checkout, npm ci, typecheck, tests and build all passed and the tarball was assembled; the publish step then failed with NODE_AUTH_TOKEN expanded to the empty string:

npm error code ENEEDAUTH
npm error need auth This command requires you to be logged in to https://registry.npmjs.org/

An organisation secret would have populated that variable in the run, so NPM_TOKEN is set neither at repository level (total_count: 0 here and in all five sibling repositories) nor at organisation level. release-npm.yml in this repository reads the same secrets.NPM_TOKEN, so it fails identically. Nothing was published, and no other release workflow was dispatched — five more runs would have proven the same thing five more times.

PyPI is blocked separately and is tracked in #6 of this repository.

Tracked as kingdom-community/.github#2, which also raises a question that has to be answered before a token is generated: all four scoped names return 404, which is equally consistent with the @kingdom-community scope existing but empty, or with the scope never having been created. A granular token cannot publish into a scope the account does not own.

---

drafted by Claude on behalf of Daniel Stephenson