Skip to content

📖✨:publish the API reference through the portal - #10

Merged
DerekNonGeneric merged 1 commit into
mainfrom
codex/sdk-markdown-api
Sep 10, 2026
Merged

DerekNonGeneric merged 1 commit into
mainfrom
codex/sdk-markdown-api

Conversation

@DerekNonGeneric

@DerekNonGeneric DerekNonGeneric commented Sep 9, 2026

Copy link
Copy Markdown
Member

Summary

Re-opens against this repository the work that was proposed where this SDK was developed before the move, and closes the gap that stopped it being publishable.

The OpenINF portal renders this SDK's API reference in its own documentation layout at /docs/sdk/<version>/api/, rather than serving TypeDoc's HTML. So TypeDoc now emits Markdown and a navigation tree, and a release packages both with a manifest naming the version and the commit they describe. The portal side is OpenINF/openinf.github.io#1895.

What changed since the original

A release now produces something. The original generated the Markdown and validated it, but nothing ever built the versioned artifact the portal imports, and no workflow ever handed one over. pnpm run docs:artifact builds it; the release workflow builds it on a run that actually published and attaches it as sdk-api-docs; RELEASING.md describes the handoff. The version is read from the workspace rather than passed in, so a released artifact can only carry the version that was released.

docs:check now checks what the portal actually enforces. It previously looked for private references and confirmed link targets existed on disk. The portal is stricter, and each of its rules now runs here against the same files:

  • every page maps onto a portal URL, so TypeDoc emitting outside README.md, packages.md, or @openinf/<package>/ fails here rather than there
  • the chrome TypeDoc writes above each page matches what the portal strips, and a heading survives it, since the portal takes each page's title from that heading
  • every internal link resolves to a page the portal actually imports, with links inside code fences left alone as examples
  • every path in the navigation tree names an imported page, which the portal would otherwise drop silently into an unnavigable sidebar entry

82 broken code examples are fixed. Rendering the corpus for the first time made these visible: those comments opened their fenced block on the @example line itself, which TypeDoc reads as text rather than as a block. Each one came out wrapped in a second fence with the comment's leading asterisk still in the first line of code. They ship in the declaration files too, so editors showed the same thing.

CI packages the artifact as well as generating it, under a placeholder version, because a release is otherwise the only thing that ever runs the packaging.

TypeDoc's invalidPath check is off, with the reason recorded in typedoc.json. The overview links to the generated package index, which TypeDoc reads as a relative file to copy and cannot find. It is that page's only inbound link and it is correct in the output, so the link stays and docs:check validates every generated link instead.

Validation

Run against the real ten-package corpus, 331 pages:

  • pnpm run build, pnpm run lint, pnpm run test — 10 packages, 0 failures
  • pnpm run docs:build — no TypeDoc warnings or errors
  • pnpm run docs:check — 331 pages pass; each rule was also confirmed to fail on a deliberately broken corpus
  • pnpm run docs:artifact — refuses to guess a version while the workspace packages disagree, as it will until changeset version runs
  • pnpm run lint:format, lint:knip, lint:spelling, lint:packages
  • pnpm install --frozen-lockfile

End to end against the portal branch: the artifact this produces imports cleanly, and the portal builds all 331 pages with no .md links left in the rendered HTML.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Documentation

    • Added a comprehensive API reference overview covering packages, navigation, versioning, and support resources.
    • API documentation is now generated in Markdown with improved navigation and package browsing.
    • Standardized more than 80 documentation examples for clearer rendering and readability.
    • Updated setup and release guidance for building, validating, packaging, and publishing API references.
  • New Features

    • Added versioned API documentation artifacts containing release metadata and page counts.
    • Added automated validation for broken links, missing pages, navigation issues, and formatting problems.
    • Integrated API documentation checks and artifact publishing into CI and release workflows.

@coderabbitai

coderabbitai Bot commented Sep 9, 2026

Copy link
Copy Markdown

Review Change StackReview Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 54eabc12-756a-4c27-a59c-ab8b6f145234

📥 Commits

Reviewing files that changed from the base of the PR and between 8851fc8 and 60f577b.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (92)
  • .changeset/example-fences-own-line.md
  • .github/workflows/ci.yml
  • .github/workflows/release.yml
  • README.md
  • RELEASING.md
  • documentation/api-overview.md
  • package.json
  • packages/assert/src/guards/is-comparable.ts
  • packages/assert/src/guards/is-deep-equal-to.ts
  • packages/assert/src/guards/is-equal-to.ts
  • packages/assert/src/guards/is-equatable.ts
  • packages/assert/src/guards/is-greater-than-or-equal-to.ts
  • packages/assert/src/guards/is-greater-than.ts
  • packages/assert/src/guards/is-identical-to.ts
  • packages/assert/src/guards/is-less-than-or-equal-to.ts
  • packages/assert/src/guards/is-less-than.ts
  • packages/assert/src/guards/is-match.ts
  • packages/util-array/src/guards/is-array-like.ts
  • packages/util-core/src/guards/is-array.ts
  • packages/util-core/src/guards/is-big-int.ts
  • packages/util-core/src/guards/is-boolean.ts
  • packages/util-core/src/guards/is-function.ts
  • packages/util-core/src/guards/is-non-nullish.ts
  • packages/util-core/src/guards/is-null.ts
  • packages/util-core/src/guards/is-nullish.ts
  • packages/util-core/src/guards/is-number.ts
  • packages/util-core/src/guards/is-object.ts
  • packages/util-core/src/guards/is-string.ts
  • packages/util-core/src/guards/is-symbol.ts
  • packages/util-core/src/guards/is-undefined.ts
  • packages/util-object/src/guards/has.ts
  • packages/util-object/src/guards/is-constructor.ts
  • packages/util-object/src/guards/is-object-like.ts
  • packages/util-object/src/guards/is-plain-object.ts
  • packages/util-text/src/guards/is-email.ts
  • packages/util-text/src/guards/is-empty-string.ts
  • packages/util-text/src/guards/is-non-empty-string.ts
  • packages/util-text/src/guards/is-string-containing.ts
  • packages/util-text/src/guards/is-string-not-containing.ts
  • packages/util-types/src/guards/is-any-array-buffer.ts
  • packages/util-types/src/guards/is-array-buffer-view.ts
  • packages/util-types/src/guards/is-array-buffer.ts
  • packages/util-types/src/guards/is-async-function.ts
  • packages/util-types/src/guards/is-async-generator-function.ts
  • packages/util-types/src/guards/is-big-int-object.ts
  • packages/util-types/src/guards/is-big-int64-array.ts
  • packages/util-types/src/guards/is-big-uint64-array.ts
  • packages/util-types/src/guards/is-boolean-object.ts
  • packages/util-types/src/guards/is-boxed-primitive.ts
  • packages/util-types/src/guards/is-data-view.ts
  • packages/util-types/src/guards/is-float32-array.ts
  • packages/util-types/src/guards/is-float64-array.ts
  • packages/util-types/src/guards/is-generator-function.ts
  • packages/util-types/src/guards/is-generator-object.ts
  • packages/util-types/src/guards/is-int16-array.ts
  • packages/util-types/src/guards/is-int32-array.ts
  • packages/util-types/src/guards/is-int8-array.ts
  • packages/util-types/src/guards/is-map-like.ts
  • packages/util-types/src/guards/is-number-object.ts
  • packages/util-types/src/guards/is-promise.ts
  • packages/util-types/src/guards/is-reg-exp.ts
  • packages/util-types/src/guards/is-shared-array-buffer.ts
  • packages/util-types/src/guards/is-string-object.ts
  • packages/util-types/src/guards/is-symbol-object.ts
  • packages/util-types/src/guards/is-typed-array.ts
  • packages/util-types/src/guards/is-uint16-array.ts
  • packages/util-types/src/guards/is-uint32-array.ts
  • packages/util-types/src/guards/is-uint8-array.ts
  • packages/util-types/src/guards/is-uint8-clamped-array.ts
  • packages/util/src/_internal/_is-object-like.ts
  • packages/util/src/guards/and.ts
  • packages/util/src/guards/has-interface.ts
  • packages/util/src/guards/is-buffer.ts
  • packages/util/src/guards/is-date.ts
  • packages/util/src/guards/is-defined.ts
  • packages/util/src/guards/is-error.ts
  • packages/util/src/guards/is-falsy.ts
  • packages/util/src/guards/is-finite-number.ts
  • packages/util/src/guards/is-int32.ts
  • packages/util/src/guards/is-iterator.ts
  • packages/util/src/guards/is-length.ts
  • packages/util/src/guards/is-nan.ts
  • packages/util/src/guards/is-negative-integer.ts
  • packages/util/src/guards/is-negative.ts
  • packages/util/src/guards/is-positive-integer.ts
  • packages/util/src/guards/is-positive.ts
  • packages/util/src/guards/is-primitive.ts
  • packages/util/src/guards/is-uint32.ts
  • packages/util/src/guards/or.ts
  • tools/build-api-artifact.js
  • tools/check-api-docs.js
  • typedoc.json

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.


📝 Walkthrough

Walkthrough

The SDK now generates and validates Markdown API references, packages versioned documentation artifacts, uploads them for published releases, and documents portal import procedures. It also reformats 82 JSDoc examples without changing runtime behavior.

Changes

API documentation pipeline

Layer / File(s) Summary
Documentation generation and validation
typedoc.json, package.json, documentation/api-overview.md, tools/check-api-docs.js
TypeDoc generates API Markdown under docs/api. The validator checks pages, links, navigation, and required files.
Versioned artifact packaging
tools/build-api-artifact.js
The artifact builder validates metadata, packages versioned documentation, and writes a manifest.
CI and release integration
.github/workflows/ci.yml, .github/workflows/release.yml
CI validates and packages API documentation. Published releases upload sdk-api-docs; version-only runs skip these steps.
Workflow and release guidance
README.md, RELEASING.md
The documentation describes API commands, artifact contents, validation, and portal import procedures.
JSDoc example formatting
.changeset/example-fences-own-line.md, packages/*/src/**/*.ts
JSDoc examples use separate @example and TypeScript fence lines. Package patch releases document the corrections.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Merge Risk: ⚪ Minimal · up to 55354

This change adds validated, versioned API-documentation artifacts to published releases and corrects JSDoc example rendering without runtime API changes. The documentation pipeline and release packaging are ready to merge.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 5…
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly identifies the main change: publishing the API reference through the portal. The emojis add minor noise but do not make the title unclear or unrelated.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch codex/sdk-markdown-api

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@socket-security

socket-security Bot commented Sep 9, 2026

Copy link
Copy Markdown

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Addedtypedoc-plugin-markdown@​4.13.01001008489100

View full report

@DerekNonGeneric

Copy link
Copy Markdown
Member Author

@coderabbitai full review

@coderabbitai

coderabbitai Bot commented Sep 10, 2026

Copy link
Copy Markdown
✅ Action performed

Full review finished.

@DerekNonGeneric DerekNonGeneric changed the title 📖✨:publish Markdown API documentation artifacts 📖✨:publish the API reference through the portal Sep 10, 2026
The OpenINF portal renders this SDK's API reference in its own
documentation layout, at /docs/sdk/<version>/api/, rather than serving
TypeDoc's HTML. That makes the generated Markdown a product artifact
with a consumer, so TypeDoc now emits Markdown and a navigation tree,
and a release packages both with a manifest naming the version and the
commit they describe.

The consumer is strict. It maps every generated path onto a public URL,
strips the chrome TypeDoc writes above each page, reads each page's
title from the heading underneath, and rewrites every internal link.
Anything it cannot map, it refuses. `docs:check` applies those same
rules here, against the same files, so a page the portal would refuse
fails the pull request that introduced it rather than the release that
would have shipped it. CI packages the corpus too, under a placeholder
version, because a release is otherwise the only thing that ever runs
the packaging.

TypeDoc reads its overview from `documentation/api-overview.md` rather
than the repository README, which links to contributor and release
instructions that have no meaning on the portal. Sources are disabled:
the paths they would name are the SDK's, not the reader's.

The release workflow builds the artifact only on a run that actually
published, since a run that just opens the version PR has no release
to describe, and attaches it for a maintainer to vendor into the
portal. RELEASING.md describes that handoff.

Rendering the corpus for the first time made eighty-two broken
examples visible. Those JSDoc comments opened their fenced code block
on the `@example` line itself, and TypeDoc reads the remainder of such
a tag as text rather than as a block: it wrapped each one in a second
fence and left the comment's leading asterisk in the first line of
code. They ship in the declaration files too, so editors showed the
same thing. The nine comments that already opened the fence on the
next line rendered correctly, which is what the other eighty-two now
do.

Signed-off-by: Derek Lewis <DerekNonGeneric@inf.is>
Assisted-by: Claude-Code:claude-opus-5
@DerekNonGeneric DerekNonGeneric added the 🚀 Status: Commit Queue Land this pull request when its checks pass label Sep 10, 2026
@openinf-commit-queue openinf-commit-queue Bot removed the 🚀 Status: Commit Queue Land this pull request when its checks pass label Sep 10, 2026
@openinf-commit-queue

Copy link
Copy Markdown

The commit queue did not land this. See https://github.com/OpenINF/sdk/actions/runs/34428554446 — the label has been taken back off, so re-applying it is a deliberate second try.

@DerekNonGeneric
DerekNonGeneric merged commit e1ce3c2 into main Sep 10, 2026
6 of 7 checks passed
@DerekNonGeneric
DerekNonGeneric deleted the codex/sdk-markdown-api branch September 10, 2026 02:16
DerekNonGeneric added a commit that referenced this pull request Sep 11, 2026
The OpenINF portal renders this SDK's API reference in its own
documentation layout, at /docs/sdk/<version>/api/, rather than serving
TypeDoc's HTML. That makes the generated Markdown a product artifact
with a consumer, so TypeDoc now emits Markdown and a navigation tree,
and a release packages both with a manifest naming the version and the
commit they describe.

The consumer is strict. It maps every generated path onto a public URL,
strips the chrome TypeDoc writes above each page, reads each page's
title from the heading underneath, and rewrites every internal link.
Anything it cannot map, it refuses. `docs:check` applies those same
rules here, against the same files, so a page the portal would refuse
fails the pull request that introduced it rather than the release that
would have shipped it. CI packages the corpus too, under a placeholder
version, because a release is otherwise the only thing that ever runs
the packaging.

TypeDoc reads its overview from `documentation/api-overview.md` rather
than the repository README, which links to contributor and release
instructions that have no meaning on the portal. Sources are disabled:
the paths they would name are the SDK's, not the reader's.

The release workflow builds the artifact only on a run that actually
published, since a run that just opens the version PR has no release
to describe, and attaches it for a maintainer to vendor into the
portal. RELEASING.md describes that handoff.

Rendering the corpus for the first time made eighty-two broken
examples visible. Those JSDoc comments opened their fenced code block
on the `@example` line itself, and TypeDoc reads the remainder of such
a tag as text rather than as a block: it wrapped each one in a second
fence and left the comment's leading asterisk in the first line of
code. They ship in the declaration files too, so editors showed the
same thing. The nine comments that already opened the fence on the
next line rendered correctly, which is what the other eighty-two now
do.

Signed-off-by: Derek Lewis <DerekNonGeneric@inf.is>
Assisted-by: Claude-Code:claude-opus-5
PR-URL: #10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant