Answers from the installed build

Half of a well-documented library’s exported names are mentioned nowhere in its own documentation. Measured against two projects that document themselves well, hono’s site covers 51% of what hono exports and zod’s covers 27%. Every one of those uncovered names is declared in the package sitting in node_modules.

So docspack sync indexes that too. Alongside the documentation packages, it reads each installed library’s own type declarations and records one entry per exported name, carrying the import a caller writes and the declaration as the installed build states it.

plaintext

+ @acme/docspack@1.4.0  128 chunks  indexed
+ hono@4.13.3  272 chunks  indexed (declarations)

This is what a documentation site cannot serve, because the site is not the artifact, and what llms.txt cannot serve for the same reason. docspack is already running in the directory where the answer is.

Declarations are looked up by name, never ranked

A library exports far more names than its documentation has pages. Ranking declarations against prose would answer every question with type machinery, so they are not in the ranking at all: a declaration reaches an answer only when the question names it exactly.

Matching is case-sensitive. Someone asking about an API writes it as it is spelled, because they read it in a stack trace or an editor. Matching loosely would let “how do I send data” pin a type called Data ahead of the page that answers the question.

Saying what the documentation does not cover

A ranker always returns its best matches, and “best” is not “relevant”. Ask about a name no documentation mentions and the old answer was three unrelated passages, formatted exactly like a correct answer, with nothing to say the subject was never covered.

Now the answer leads with the declaration and ends with the difference:

text

## hono@4.13.3/ValidationTargets
Source: hono@4.13.3 — declared in dist/types/types.d.ts, read from the installed package

# ValidationTargets

Declared by `hono/types`. This is the installed build's own declaration, not prose.

    import { ValidationTargets } from "hono/types";

    export type ValidationTargets = { … };

---

NOTE: `ValidationTargets` is exported by the installed library but mentioned in no
documentation package here. The declaration above is the installed build's own, not prose
anyone wrote.

A question that names no symbol — “how do I stream a response” — has no name to be absent, so nothing changes for it. This closes the half that can be checked mechanically.

Turning it off

bash

npx docspack sync --no-artifacts

Declarations are read from packages this project depends on directly, and only from names an entry point in the exports map actually publishes. A package that ships no type declarations is skipped without comment: most of a dependency tree is not what anybody asks questions about.

What changed between two versions

The store is global, so a version indexed for one project on this machine is available to every other. docspack changed compares two of them:

bash

npx docspack changed hono

plaintext

hono 3.12.12 → 4.13.3  246 added, 3 removed

gone  COMPOSED_HANDLER, UndefinedIfHavingQuestion, childrenToString

new   ALBProcessor, Accept, AddedSSGDataRequest … and 226 more (--json for all)

237 new names that no documentation package here mentions:
…

Upgrades are overwhelmingly additive. The gap between what a model remembers and what is installed is mostly things that did not exist yet, not things that broke — and the useful report is what exists now that an older release did not have. Nothing is fetched: both versions come from the local index, and a version that is not indexed is an error saying so rather than a network request.

Coverage

The same comparison, pointed at a documentation package instead of a version:

bash

npx docspack list --coverage

plaintext

@acme/docspack@1.4.0  128 chunks  indexed
  documents 189/367 (51%) of acme's exports
  missing: ValidationTargets, NotFoundHandler, ErrorHandler, …

docspack doctor reports the same number as a note. It is never a failure and --strict never promotes it: a page listing every export and explaining none would score full marks, so this is a number for an author to read rather than a gate. A package documenting a command line rather than a library API will score near zero and be perfectly correct — the note’s own suggested fix says so.