These lines are written by the build, and the catalog has moved since they were
last written. Committing the build's own answer keeps the record true instead of
showing a version that is no longer inside the tarball.
Co-authored-by: Hanzo Dev <[email protected]>
A version written into a manifest is written into every manifest that wants it,
which is how eslint came to exist in a hundred and four forms across this estate
and how a package came to resolve twice at run time. The catalog moves the number
out of the manifest: a manifest names the package, the workspace names the
version.
Four are held below their latest because the newer release cannot be used, and
the reason is recorded rather than the version alone: @noble/hashes 2 renamed
every subpath the web3 stack imports, @splinetool/runtime 2 depends on a package
that was never published, @dynamic-labs 5.4.1 the same, and react-resizable-panels
3 points its types condition at the bundle.
Co-authored-by: Hanzo Dev <[email protected]>
Every dependency on a @hanzo/@luxfi/@zooai package now names the same version
across the repo: a catalog entry where pnpm supports one, an exact pin where it
does not, and a range only where a peer genuinely means one.
pnpm itself is pinned too — the estate ran eighteen different versions, five of
them too old to read a catalog.
Co-authored-by: Hanzo Dev <[email protected]>
Correcting this branch's own conflict resolution, not upstream work. Origin
already imported `compile`, `ExampleRequestItem` and `RequestTabsRenderContext`
— relatively, further down the file — so taking the rescued commit's absolute
`@/ui/...` forms declared each name twice and tsdown refused to parse:
[PARSE_ERROR] Identifier `ExampleRequestItem` has already been declared
The rescued commit fixed real missing imports on ITS lineage; on this one they
were already there. Keeping origin's relative form.
Co-authored-by: Hanzo Dev <[email protected]>
Rendering a request body threw for any media type the adapter registry did
not cover, which ended the export of all 6,952 pages over one operation:
Error occurred prerendering page "/docs/openapi/smart-http/gitUploadPack"
Error: Media type application/x-git-upload-pack-request is not supported
(in /v1/git/{org}/{repo}/git-upload-pack)
Nothing in that subtree needs an adapter: it renders the schema and the
TypeScript definitions. The adapter is needed to SEND a body from the
playground, and `createBrowserFetcher` already handles its absence there with
a readable 400 naming the missing adapter. So the throw protected nothing and
cost the site — git's smart-HTTP protocol has a real media type, and a
reference that refuses to document it is worse than one that documents it and
says it cannot be sent from the browser.
Co-authored-by: Hanzo Dev <[email protected]>
(cherry picked from commit 811a5e8b30845fb94579039cd11996d1147dc163)
The upstream merge (9b95157ad) dropped the body of `renderResponse` from
`ui/operation/response-tabs.tsx` and kept the call to it. tsdown does not
type-check, so it shipped and the hub build died two phases later:
Generating static pages using 19 workers (0/6952) ...
ReferenceError: renderResponse is not defined
Restored from 337c93491, the last revision that had it, adapted to the
current signature: `renderResponseTabsDefault` is synchronous now, so the
renderer is too, and each `<Tab>` carries a key. Behaviour is the one the
imports in that file already describe — one accordion per example when there
are several, the example inline when there is one, the `empty` label when
there are none.
The same sweep over the rest of the package, by type-check rather than by
build failure:
ui/client/i18n.ts `useTranslationsBase` was the old name of the
context's `useTranslations`; `TranslationValue` was
never imported. `I18nLabel` is what the restored
renderer calls for an empty response, so this was
the next ReferenceError in line.
i18n.ts imported `TranslationsOption`, which no UI context
exports, and used `TranslationValue` /
`TranslationsAPIExtension`, which core does.
ui/schema/client.tsx `CheckIcon` and `LinkIcon` missing from the
lucide-react import beside them.
playground/fetcher.ts read `options.bodyMediaType` inside `fetch(url, data)`
— the parameter is `data`.
tsc --noEmit -p packages/openapi
before 17 errors
after 2, both real API drift rather than a missing name:
`@scalar/api-client-react` renamed its hook, and a test helper
references a boundary it does not import. Left for a decision.
(cherry picked from commit d7f880c8feb0670153c8ca7b1b71a3a5d6aac0bf)
Co-authored-by: Hanzo Dev <[email protected]>
`ui/base.tsx` referenced five identifiers it never imported. tsdown does not
type-check, so the package built clean and the references became runtime
ReferenceErrors. One of them took the hub build down:
Error occurred prerendering page
"/docs/openapi/orgs/post_v1_orgs_org_entitlements"
ReferenceError: PlaygroundAuthProvider is not defined
`base.tsx` is the server renderer; it reaches client components only through
the lazy boundary, which is where `PlaygroundAuthProvider` lives. The default
playground provider now closes over it there, beside the sibling that already
reached `PlaygroundClient` that way, and the boundary module exports it so
both boundaries carry the same set. The client renderer (`create-client.tsx`)
was already correct — it imports `AuthProvider` directly, which a client
module may do.
`pickSchema`, `encodeInternalRef` and `compile` are the other three: all live
(`renderPlaygroundDefault`, `generateTypeScriptDefinitions`), all one import
away, all latent ReferenceErrors on the playground and TS-definition paths.
`ExampleRequestItem` and `RequestTabsRenderContext` were type-only.
tsc --noEmit -p packages/openapi
before 8 errors in ui/base.tsx
after 0
Four files in the package still carry the same defect — `i18n.ts`,
`ui/client/i18n.ts`, `playground/fetcher.ts`, `scalar/client.tsx` — but each
needs an API decision (a renamed upstream export, a changed @scalar surface),
not an import. Left alone rather than guessed at; nothing on the current
render path reaches them.
(cherry picked from commit 10ccb563cc235268f0f7abfd1942f10a5d297c04)
Co-authored-by: Hanzo Dev <[email protected]>
hanzo.yaml's iam_ApiController.GetWebhooks requires `test_apiKey`;
components.securitySchemes defines bearerAuth, BearerAuth, oauth2, apiKey,
serviceKey and s3Auth, and not that. Every consumer looks the id up and then
reads a property of it — schemes[id].deprecated in useAuthInputs, again in
SecurityRequirement — so one line of a 58k-line document threw "Cannot read
properties of undefined" out of a prerendered page and ended the whole export
at 1510/6041 pages.
parseSecurities is where a requirement becomes entries, so it is where the
document stops being untrusted input: drop ids the document does not define,
name the operation and the scheme in the warning, and nothing downstream has to
re-check. An undefined scheme carries no credential to render or send, so
dropping it is also what it means.
The document bug is real and still wants fixing in hanzoai/openapi — this only
stops it costing the site.
Co-authored-by: Hanzo Dev <[email protected]>
c04da7fb6 took 334 upstream commits and resolved the conflicts by keeping this
fork's import lines above upstream's bodies. The bodies then reached for names
nothing imported — useMemo, CheckIcon, LinkIcon, useApiClient, compile,
ExampleRequestItem, RequestTabsRenderContext, TranslationValue,
TranslationsAPIExtension, ClientBoundary, processDocument — 24 type errors in a
package that kept publishing, because tsdown does not type-check. Each one is
restored from where upstream imports it, under our name for the fork.
renderResponse was the one that was not an import. The resolution kept our
`{tabs.map(renderResponse)}` and took upstream's rewrite of the function above
it, which had inlined that body and deleted the definition — a call with no
callee. Reconstructed from upstream's inlined form, keeping the fork's deltas
(base-ui tabs, and hanzo_docs_openapi_requests to match the responses group id
rather than leak the upstream brand into a storage key).
Three fixes come with it, all the same merge:
- fetcher returned the old {status,type,data} error shape from a `data`
parameter it called `options`, against upstream's new FetchResult union.
- request-tabs and schema/client carried imports for symbols they never use,
two of them from the Radix package.
- openapi-sampler goes: upstream replaced it with @/utils/schema/sample and
response-tabs was the last importer still pointing at the package.
63 tests pass — three suites could not even import test/utils before this.
Co-authored-by: Hanzo Dev <[email protected]>
apps/docs imported the same component library under three names — 11 files
from `@hanzo/docs/ui/*` (a pure re-export shell), 10 from `@hanzo/docs-ui`
(the Radix fork), plus 5 hand-copied shadcn files under components/ui.
All of it now resolves to `@hanzo/docs-base-ui`.
The 5 local copies are deleted. badge, hover-card, select and the container
card move into base-ui on `@base-ui/react` — preview-card is the hover-card
analog and Select.Value already takes `placeholder`, so the swap is 1:1 and
introduces no Radix. buttonVariants gains `xs`/`md`/`lg` and `link`, purely
additive, so no existing caller changes. Three Radix packages leave
apps/docs; `presence` and `tooltip` stay because non-shadcn code uses them.
global.css now takes base-ui's preset rather than the Radix fork's. The two
are not duplicates: `neutral.css` defines the colours, `preset.css` carries
base styles plus the `@source inline` safelists. Only `default-colors.css`
declares a `--color-fd-*` value, and it is byte-identical across both forks,
so no colour moves.
`types:check` never ran. pnpm installs the mdx bin scope-stripped as
`docs-mdx`, so `@hanzo/docs-mdx &&` died at `sh: no such file` and took
`tsc` with it — silently, in every app, for `lint` too. Fixed in all 32
scripts. apps/docs reports 107 first-party errors; that is the real number,
unchanged by this commit.
Also unbreaks two undefined references in openapi's server entry that a
large upstream merge left behind: PlaygroundAuthProvider was used but never
imported, and pickSchema/encodeInternalRef were orphaned utilities. Both
crashed the docs export. More remain in that package (renderResponse is a
missing function, not an import) — noted, not guessed at.
Co-authored-by: Hanzo Dev <[email protected]>
Three things the workspace disagreed with itself about.
Versions. apps/docs ran ahead on next 16.2.6 / react 19.2.6 / TS 6, the other
21 apps trailed on next 16.1.6 / react 19.2.3 / TS 5.9.3, and the packages sat
somewhere between with five different @types/react pins. Everything is now on
the newest patch of the line it was already on — react 19.2.8, next 16.2.12,
@types/react 19.2.18, @types/react-dom 19.2.4 — and the TS-5 stragglers join
the TS 6.0.3 the root and every package already used. No majors were invented:
6.0.3 IS the top of the 6.x line, and TS 7 is blocked because [email protected]
declares `typescript: ^5.5.0 || ^6.0.0`.
The duplicate key. next.config.mts declared `transpilePackages` twice in one
object literal, so the later list won and @hanzogui/shell and @hanzo/brand had
never been transpiled — the comment explaining why they must be outlived the
setting it described. tsc had been reporting this the whole time as
next.config.mts(193,3) TS1117; the app's `types:check` never reaches tsc (its
script starts with a bare `@hanzo/docs-mdx`, which is not the bin's name and
fails immediately), so nobody saw it. One list now, both groups in it.
Dead weight. Twelve packages apps/docs declared and no file, config, script or
browserslist field referenced: @radix-ui/react-dialog, @floating-ui/react-dom,
@mixedbread/sdk, @orama/orama, openapi-sampler, react-remove-scroll,
algoliasearch, gray-matter, tinyexec, tinyglobby, @types/three (types for a
package that isn't installed) and shadcn (no components.json exists anywhere in
the repo, so the CLI was never initialized). The ones that are real
dependencies of packages/openapi, packages/core and packages/cli keep their own
copies — pnpm's node_modules is isolated, so nothing lost a resolution.
@orama/core stays: apps/docs/app/static.json/route.ts pulls OramaDocument
through @hanzo/docs-core/search/orama-cloud, which types against it.
Verified against a clean worktree at HEAD, since the working tree carries
gigabytes of untracked synced project docs that CI never checks out:
turbo build, apps + packages 43/52 before, 43/52 after, same 9 failures
docs export 1764 html pages, byte-identical page count
deploy.yml gate index/docs/services present, /docs has nav
tsc --noEmit in apps/docs 325 errors before, 324 after (the TS1117)
vitest 169 passed / 13 failed, both sides
The 9 build failures and 13 test failures are unchanged from HEAD and none are
version-related: 7 sibling apps cannot resolve @hanzo/mdx:collections/server
under `next build --webpack`, zen-docs has a committed docs/server.ts importing
a deleted zen5-coder-flash.mdx, and packages/preview cannot resolve its own
@/lib/source alias under waku/vite.
Co-authored-by: Hanzo Dev <[email protected]>
openapi/story/cli/python imported @hanzo/docs-base-ui (and others) without
declaring it. Under pnpm strict isolation Turbopack resolves from the importing
package's node_modules and couldn't find base-ui's subpath exports
(components/ui/button, components/tabs, utils/use-copy-button) — webpack was
lenient. Declare the missing workspace deps so resolution is deterministic.
Same dropped-import class: page-actions (radix-ui/base-ui) and openapi's client
i18n call renderTranslation() without importing it from @hanzo/docs-core/i18n.
inputs.tsx imported FormatFlags from a path that no longer exists; the util
lives at src/utils/schema/to-string.ts. The stale path was silently
externalized by tsdown and leaked into dist, breaking the docs Next build.
Revert the exploratory tsdown alias — the fixed import resolves under the
package's existing default resolution.
The docs Next build failed on 24 unresolved modules, so no content pages
ever shipped (every /docs sub-page 404s live). Root causes, all fixed:
- @hanzo/docs-openapi dist leaked its internal `@/` path alias
(`@/utils/schema-to-string`, `@/playground/*`, `@/requests/*`) because
tsdown ran with unbundle:true and no alias mapping. Add
`alias: { '@': src }` so the built dist resolves to relative paths.
- @hanzo/docs-openapi imported `openapi-sampler` without declaring it — add
it as a dependency so consumers can resolve it.
- apps/docs imported packages it never declared (phantom deps under pnpm's
strict node_modules): @hanzo/docs-base-ui, @hanzo/logo, @hanzo/iam,
@radix-ui/react-select, @radix-ui/react-slot, openapi-sampler. Declare them.
- lib/source imports the bare `collections/server` specifier but only
`@hanzo/mdx:collections/*` was aliased. Alias the bare form too.
Three phantom/path stragglers the prior normalization passes did not cover,
all blocking the package build chain (`turbo run build --filter=./packages/*`):
- packages/cli: `@hanzo/docs-cli/build` was imported by apps/docs +
shared/radix-ui/base-ui registries but the cli package never exposed it.
The real registry-build API is fuma-cli/compiler (cli already deps on
fuma-cli). Add src/build.ts re-export + ./build export + tsdown entry so
`@hanzo/docs-cli/build` resolves to the real symbols (compile, writeRegistry,
Registry, Component, Reference, SubComponentReference, CompileOptions).
- packages/hanzo-docs core/content/index.ts: barrel re-exported a bare
fumadocs-core/content subpath that exists in no version (upstream or fork).
Aggregate the real sibling modules (./github + ./toc) instead — no symbol
collision (getGithubLastEdit vs getTableOfContents).
- packages/openapi src/ui/client/full.tsx: import of ./components/codeblock
resolved one dir too shallow (file lives in src/ui/client/, codeblock in
src/ui/components/). Fix to ../components/codeblock, matching create-client.tsx.
Verified: full package chain builds green from cold cache (29/29, node 24.18).
The fumadocs-fork rebrand left ~13 apps + examples referencing packages under
names that don't exist in the workspace (in BOTH directions: some kept
fumadocs-*, some became @hanzo/docs-*). pnpm install failed outright. Mapped
every reference (deps + imports, 607 source + 61 package.json) to the package
that actually exists, by suffix:
@hanzo/docs-{core,mdx,ui,base-ui} → fumadocs-{core,mdx,ui} / @fumadocs/base-ui
@fumadocs/{story,cli,mdx-remote,tailwind} → @hanzo/docs-{story,cli,...}
fumadocs-{docgen,epub,twoslash,typescript} → @hanzo/docs-{...}
drop phantom eslint-config-custom
Guarded @hanzo/docs-mdx vs -mdx-remote. Also fixes a pre-existing cli bug
(createConfigSchema referenced undefined isSrc) that blocked the package build.
Verified: pnpm install resolves clean (46.8s, was broken); package dist
regenerates phantom-free from the corrected source (hanzo-docs 430→0). Full
app build-green is blocked only by a node v26 toolchain bug in fumadocs-mdx's
config loader (repo targets node >=24.14; CI node builds it).
* feat(openapi): anchor links on schema properties
Each property rendered inline in a request body, response body, or parameter
now gets a stable id and a hover-revealed link icon, enabling deep links to
specific fields from guides. Ids follow:
- body-<prop> for request bodies
- response-<status>-<prop> for responses
- parameters-<location>-<name> for parameters
A new idPrefix option on SchemaUI opts other Schema renderings into the same
behavior. See fuma-nama/fumadocs#3322.
* feat(openapi): deep-link nested schema properties
Extend the property anchor scheme to support hashes that point inside a
popover or below an array's "Show array" collapsible. Schema-internal
segments are joined with `.` so `#body.user.address.street` resolves
unambiguously regardless of dashes in property names.
On hash match, the inline anchor scrolls into view, the matching popover
auto-opens with its breadcrumb pre-navigated, the array collapsible
expands, and oneOf/anyOf tabs switch to the variant containing the
targeted field. The deep target is consumed after the first auto-open,
so subsequent user clicks on the same trigger get the base view; a
different deep hash re-arms it.
The hover anchor is now a copy-link button (matches fumadocs heading
anchors) that writes the full URL to the clipboard and updates the
address bar via history.replaceState (no hashchange, no popover reset).
* address PR review feedback
- Clarified the changeset: split anchor ID rules by context (request/response property paths vs flat parameter anchors) so dots aren't implied to apply to parameters.
- Namespaced anchors by media type when an operation has multiple request-body or response content types: prefix becomes `<media-slug>-body` / `response-<status>-<media-slug>`, and the content-type SelectTabs auto-switches to the targeted tab when a deep link arrives. Single-content-type operations keep the simple `body` / `response-<status>` form.
- Made findUnionPropMatch validate the *full* remaining path (via new pathResolves helper) so two variants that share the first prop name no longer race; the wrong tab can't be selected for a deep hash anymore.
- Reset SchemaUIPopover breadcrumb state when initialPath changes so a fresh deep hash takes effect on an already-open popover.
- Replaced the lossy slugifyPropertyName with encodeURIComponent (plus % encoding for `.`) so property anchors stay collision-safe across case-only differences, punctuation-only differences, and non-ASCII keys, while `.` remains exclusively a path separator.
* address PR review feedback
- Fix potential hydration mismatch in useTabValueFromHash by initializing state with the fallback value and resolving from the URL hash inside useEffect; the deep-linked tab now corrects after hydration on the client.
* fix(openapi): move useTabValueFromHash into a client component
The previous hydration-mismatch fix put `useEffect`/`useState` directly in
`operation/index.tsx`, which is a Server Component — Next refused to compile
because RSC modules can't import client-only React APIs. Extract the
hash-aware tab wrapper into `operation/hash-tabs.tsx` (with `"use client"`)
and switch both body and response sites to `HashAwareSelectTabs`. The parent
tree stays server-side; only the tab wrapper hydrates on the client.
* address PR review feedback
- Wrap decodeURIComponent in try/catch in both deep-link hash parsers so a malformed percent-encoded fragment (e.g. `#body%`) is treated as "no target" instead of throwing URIError and breaking tab / popover resolution.
* address PR review feedback
- Match the URL hash against DOM ids using the raw fragment first, with the fully-decoded form as a fallback, in both DeepLinkProvider and hash-tabs. Property anchors are generated via slugifyPropertyName (which percent-encodes reserved chars like `.`), so DOM ids contain the encoded form; decoding the hash before lookup caused links like `#body.foo%2Ebar` to miss the matching element.
* redesign
* fix types
---------
Co-authored-by: Fuma Nama <[email protected]>
* OpenAPI: render deprecated badge for deprecated operations
Show a yellow "Deprecated" badge for any OpenAPI operation marked
`deprecated: true`. The badge appears in two places: inline with the
operation heading when `showTitle` is true, and as a standalone header
above the playground card when `showTitle` is false (which is the
default for individual operation pages generated by `openapiSource`).
This restores the behaviour originally added in #2417, which was lost
during the v9→v10 move of the operation renderer from
`packages/openapi/src/render/operation/index.tsx` to
`packages/openapi/src/ui/operation/index.tsx`. The parameter-level,
schema-property-level and auth-scheme-level deprecated badges all
survived the refactor; the operation-level one was silently dropped.
The example spec's `deletePlanet` operation already claimed in its
description to be deprecated but never set the flag (inherited from the
upstream Scalar Galaxy fixture). Setting it both fixes the
inconsistency and provides a visible demo for the new badge.
* OpenAPI: improve operation deprecation styles
---------
Co-authored-by: Fuma Nama <[email protected]>
zeekayandHanzo Dev