The deprecated `useRenderTool` shim landed after these pages were written, so
they described a harder break than the code delivers — "React Native has no
render-tool API of its own", and a migration table presenting the old hook as
simply gone.
reference/react-native/hooks/useRenderTool:
- The overview and the migration narrative now say what actually happens: the
name still exists, still works this release, routes by shape, warns, and goes
away in the next minor. The routing table is the shim's three rules verbatim
(src/hooks/useRenderTool.ts `routeFor`), including the unconditional wildcard
and why it is unconditional.
- The warning is quoted from the source string rather than paraphrased, and gets
its own "What the warning does not cover" section: dev-only gate, per-name
dedup for the module's lifetime, silent when no old field is present, and
emitted from an effect so an unmounted screen never warns.
- "Three shapes the compiler does not catch" is kept, not deleted. It is now
framed as what the shim exists to route — and as what to audit by hand anyway,
because the notice is development-only and because all three go back to
degrading silently once the shim is removed.
- Two new migration rows for losses the table omitted: bare `RenderToolProps`
is now `TS2314` (core's `S` has no default where RN's `T` did), and the
`args` -> `parameters` render-prop rename is still `TS2339` even through the
shim — verified with tsc, the shim restores the old CONFIG fields only. The
`RenderToolFunction<T>` row now points somewhere instead of saying "gone".
- `parameters` was documented as `Partial<T> | T`, using a generic this page
renamed to `S` and explicitly warns is the schema rather than the arguments.
It is `Partial<InferSchemaOutput<S>> | InferSchemaOutput<S>`
(react-core/src/v2/hooks/use-render-tool.tsx:9-31).
reference/react-native/hooks/useFrontendTool had zero mentions of `ReactElement`,
`ReactNode` or `FlatList` despite being where the migration sends people. It now
documents that its `render` is a `React.ComponentType` and therefore accepts a
bare string that throws on a device, and points at the opt-in
`FrontendToolRenderFunction<T>`.
docs/frontends/react-native and packages/react-native/USAGE.md (which ships in
the npm tarball — no `files` array, no `.npmignore`) get the same corrections at
their own length.
Every code sample added here was typechecked by pasting it into the package and
running `tsc --noEmit`, including the ones asserted to FAIL. Internal links and
heading anchors were checked mechanically against the content tree.
Rewrites the RN reference page for core's hook, points tool-plus-renderer users
at `useFrontendTool`, and carries the migration table. That table is the actual
consumer-facing channel for this break: the release-note collector
(scripts/release/lib/changes.ts) reads `git log --format=%H %s` into a
`{ hash, subject }` type, so a `BREAKING CHANGE:` footer has nowhere to land
(#6479).
The migration's loud-failure guarantee is stated precisely rather than
absolutely, because the absolute form is false. TypeScript's excess-property
check rejects an old call site (`TS2769` on `description`) only when the config
is a fresh object literal with those fields written inline; the renamed render
prop gives `TS2339`. Three shapes escape it, each named on the page: a hoisted
config whose `render` ignores its props, the same fields arriving via a spread,
and an untyped or `@ts-nocheck` call site. The last is the one to worry about —
core's bridge spreads `{ ...props, parameters: props.args }`, so `args` still
arrives at runtime and an old renderer keeps painting correctly while the tool
has silently stopped being registered.
Retires three § Known limitations entries this convergence closes (the wildcard,
`followUp`/`available` forwarding, and `handler`'s missing context argument) and
leaves the unrelated ones intact.
Deletes a false claim the previous docs shipped: that comparing `status` against
a bare string literal does not typecheck. A string-enum member is assignable to
its own literal type, so the comparison compiles and narrows in every direction
— verified with tsc in all four combinations. RN's `status` moves from the
`ToolCallStatus` enum to core's string-literal union, and that is explicitly not
a break; no migration work follows from it.
Also updates packages/react-native/USAGE.md, which still taught the deleted API.
That file ships in the published tarball — package.json declares no `files` array
and there is no .npmignore — so the package was documenting an API the package no
longer has. Its remaining samples were compiled against the shipped overloads.
Corrects the primary guide's claim that a `ReactElement | null` render return is
React-Native-specific: it is identical on the web. What is RN-specific is the
consequence of `useFrontendTool`'s looser render type, where a bare string
typechecks and then throws inside a `FlatList`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The `@copilotkit/react-native` barrel statically re-exports the prebuilt chat
UI (CopilotChat / CopilotModal / CopilotSidebar / CopilotPopup, which import
`@gorhom/bottom-sheet`) and `useAttachments` (which imports
`expo-document-picker` + `expo-file-system`). Those are optional peer deps, but
a static re-export still forces Metro to resolve them at bundle time. A headless
consumer that uses only `CopilotKitProvider` + `useAgent` + `useFrontendTool`
(a fully custom UI) had to install every chat/attachment native dep or stub them
in `metro.config.js`, or the release bundle fails with
`Unable to resolve module expo-document-picker`.
Add a lean `@copilotkit/react-native/headless` entry that re-exports only the
provider, the platform-agnostic hooks, the render-tool registry, and the
core/AG-UI types — none of the chat UI or `useAttachments` — so those native
deps never enter the bundle graph and the metro-stub workaround is retired.
Mirrors `@copilotkit/react-core/v2/headless` (#5883): a standalone entry file,
wired into the tsdown entry list, the package.json `exports` map, and
`sideEffects` (it side-effect-imports the polyfills). The default barrel now
does `export * from "./headless"` and layers the chat UI on top, so it stays
fully backward compatible. Adds a static import-graph regression test asserting
the headless graph never reaches the chat/attachment modules or their native
peer deps.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add peer dependencies, export new components and hooks from package entry point, integrate RenderToolProvider into CopilotKitProvider, configure vitest and tsdown, add usage documentation.
Maxim