zeekayandHanzo Dev 7025aff29b fix(docs): generate .source at build time, and load it the way the runtime expects ...

With the lockfile resynced the docs job got past install and failed at build:

    Module not found: Can't resolve './.source'   (from lib/source.ts)

.source is GENERATED and gitignored, and this package had no step that produced
it — `build` was a bare `next build` and there was no postinstall. It only ever
worked where a stale .source happened to be lying around, which is why a laptop
built it and a fresh checkout never could.

Three things, each found by making the previous one fail differently:

1. Nothing generated .source. Now `hanzo-mdx source.config.ts .source` runs in
   both build and postinstall, the shape luxfi/consensus already uses.

2. `import { docs } from "@/.source"` is a DIRECTORY import and the generator
   emits no index — it writes browser.ts / dynamic.ts / server.ts. consensus
   imports "@/.source/server"; so does this now.

3. `docs.toFumadocsSource()` did not exist, and neither did `toSource()` — the
   generated code targets `@hanzo/docs/mdx/runtime/server`, while lib/source.ts
   pulled its loader from `fumadocs-core`, mixing two stacks. It resolved
   @hanzo/docs 16.2.7 where consensus runs 16.4.x and works. Loader now comes
   from `@hanzo/docs/core/source` with `toSource()`, and the range is pinned
   ^16.4.1 to match consensus rather than left to drift.

Verified as a fresh checkout would run it — node_modules and .source deleted
first:

    pnpm install --frozen-lockfile   OK
    .source after install            generated by postinstall
    pnpm build                       OK

Only docs/ is touched; the dashboard/ work in this tree is left alone.

Co-authored-by: Hanzo Dev <[email protected]>

2026-08-02 06:22:34 -07:00

..

source.ts

fix(docs): generate .source at build time, and load it the way the runtime expects

2026-08-02 06:22:34 -07:00