0.1.0 is unpublished on npm and PyPI, so 505 lines of forked GitHub-content code stay duplicated across two orgs

[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%2fgithub-docs	HTTP 404
PyPI	https://pypi.org/pypi/github-docs/json	HTTP 404
Releases	gh release list -R kingdom-community/github-docs	empty
Tags	gh api repos/kingdom-community/github-docs/tags	0
npm release runs	gh run list -R kingdom-community/github-docs --workflow release-npm.yml	zero runs, ever
PyPI release runs	gh run list -R kingdom-community/github-docs --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, each carrying the same one-line rationale at line 3:

# Manual only. A release is a decision, not a side effect of a merge.

That is not in question. What is recorded here is that the decision has never been made, for either half, and that it is the only thing standing between this library and the two sites that duplicate it.

CI on main is green (ci.yml, run 33472116641, fecf87c) and gates both halves — a JavaScript matrix (typecheck, test, build) and a Python matrix (pip install ., unittest discover, python -m build). js/README.md:17 instructs npm install @kingdom-community/github-docs and python/README.md:20 instructs pip install github-docs; both 404 today.

What is waiting on it

This is the only one of the six libraries with a fork in two organisations. Measured 2026-09-06:

The private site this library was extracted from — 391 lines:

Forked file	Lines
services/githubContent.ts	196
utils/markdownUrl.ts	111
utils/guides.ts	84

Dans-Plugins/dansplugins-dot-com — 114 lines:

Forked file	Lines
utils/github.ts	75
utils/guides.ts	39

505 lines across two sites and two organisations, both fetching and rendering documentation out of GitHub, neither able to share a fix with the other.

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

That two-org spread is the argument for prioritising this one. The other five libraries each serve a single site; the divergence cost here is already being paid twice, in codebases maintained on different schedules, and the two forks are not the same size — 114 lines against 391 suggests they have already diverged in capability, not merely in copies.

What must happen

1. Confirm the publish credentials exist — they are two different mechanisms, and both workflows are environment-gated.
   • npm. release-npm.yml:39 reads secrets.NPM_TOKEN, and the job declares environment: npm (line 20). gh api repos/kingdom-community/github-docs/actions/secrets reports total_count: 0, so nothing is set at repository level — but an organisation-level secret, or an environment-scoped one, would satisfy it. 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 environment: pypi (line 15), and its comment at lines 29-30 states the prerequisite: "configure this repo + workflow as a publisher on PyPI, and no long-lived API token has to exist anywhere." Whether that publisher has been registered on PyPI could not be checked from here.
   • One observation bearing on both: gh api repos/kingdom-community/github-docs/environments returns {"total_count": 0, "environments": []} — neither the npm nor the pypi environment currently exists in this repository. GitHub materialises a referenced environment at run time, so this need not block a run, but a PyPI trusted publisher must be registered against the exact repository, workflow filename and environment name, and any environment-scoped NPM_TOKEN would have nowhere to live yet. Both are worth settling before the first dispatch rather than from a failed job.
2. Decide whether 0.1.0 is the right first version, and whether the halves ship together. Both manifests read 0.1.0. Publishing them in step keeps that alignment meaningful; publishing one alone begins a divergence that will need a stated policy.
3. Fire the workflows from main. release-npm.yml re-runs typecheck, test and build before publishing with --provenance --access public, and takes a tag input defaulting to latest. release-pypi.yml re-runs the Python tests and python -m build before uploading. Note that, unlike this org's session-client, neither workflow here has a dry_run input — a dispatch publishes.
4. Unblock the consumer issues in both sites so each can replace its fork with a dependency.

Open questions

• Should the Python distribution be published at all yet? No consumer for it has been found — both identified forks are TypeScript, in two Next.js sites. The Python half is maintained, CI-gated across a Python matrix, and has, as far as could be established, nobody to install it. Publishing anyway claims the name and keeps the two halves in lockstep; holding it avoids committing to a public API for zero users. The name argument is sharper here than on the npm side: github-docs is an unscoped, extremely generic PyPI name with no namespace protecting it, where the npm half is safe inside @kingdom-community. This search was incomplete — the org-scoped code searches for Python consumers hit GitHub's search rate limit partway through and did not fully cover two of the four organisations, so the absence of a Python consumer is probable rather than proven.
• Is green CI sufficient to release? With no dry_run input on either workflow, a first dispatch is irreversible on both registries — an npm version cannot be re-published and a PyPI version cannot be re-uploaded. A local npm pack from js/, and a local python -m build plus twine check from python/, would validate the artefact shapes first. Adding a dry_run input to these two workflows, matching the pattern already used in this org's session-client, is worth considering as separate work.

---

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]

The downstream adoption issue for the public consumer has now been filed and is blocked on this one:

• Dans-Plugins/dansplugins-dot-com#308 — utils/guides.ts and utils/github.ts reimplement this library without its URL-scheme allowlist or its fetch bounds.

That is a sharper statement of the divergence than the line counts above convey: the fork is not merely a duplicate, it is a duplicate missing two safety properties the library has. Neither can be delivered to it while 0.1.0 returns a 404 from the registry.

The second consumer is private and is tracked separately; it is not named here.

---

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