fix(@tinacms/astro): astro check rejects generated rich-text fields passed to TinaMarkdown (tinacms#7605)

## Problem

`@tinacms/cli` 3.0.0 (tinacms#7229) types rich-text fields as
`TinaMarkdownContent` from `tinacms`:

```ts
body?: Maybe<Scalars['RichText']['output']>; // TinaMarkdownContent
```

`<TinaMarkdown>` in `@tinacms/astro` types `content` as
`TinaRichTextContent`, whose root has the literal `type: 'root'`.
`TinaMarkdownContent` has `type: string`, so TypeScript rejects the
generated field:

```
Type 'TinaMarkdownContent | null' is not assignable to type 'TinaRichTextContent'.
  Type 'TinaMarkdownContent' is not assignable to type 'TinaRichTextRoot'.
    Types of property 'type' are incompatible.
      Type 'string' is not assignable to type '"root"'.
```

An Astro project that passes a queried body straight to the renderer
gets this error from `astro check`. `examples/astro/visual-editing`
passes `data._body` in `PostBody.astro` and `BlogBody.astro`. That
example does not run `astro check`, so CI did not catch it.

Before tinacms#7229 the field was `any`, and the same call compiled.

## Change

`content` accepts both types, as a root or as an array of nodes. The
React `<TinaMarkdown>` accepts the same two forms.

```ts
type GeneratedRichTextContent = {
  type: string;
  children: GeneratedRichTextContent[];
};

export interface TinaMarkdownProps {
  content:
    | TinaRichTextContent
    | GeneratedRichTextContent
    | GeneratedRichTextContent[];
  components?: CustomComponentsMap;
}
```

- `TinaMarkdown.astro` and the placeholder in `index.ts` both use
`TinaMarkdownProps`. The two prop declarations can no longer drift
apart.
- `@tinacms/astro` does not depend on `tinacms`, so
`GeneratedRichTextContent` copies the shape instead of importing it. It
stays private to `types.ts`.
- `TinaRichTextContent` does not change. Code that narrows on it keeps
its literal types.
- Rendering does not change. Both types describe the same Plate AST.

A component that wraps `<TinaMarkdown>` can type its own prop as
`TinaMarkdownProps['content']`.

## Why not change the CLI

The CLI could detect `@tinacms/astro` and emit `TinaRichTextContent`
instead. That adds framework detection to codegen, and Astro users who
already moved to CLI 3 would see their generated types change a second
time. The mismatch sits in the renderer's prop, so the fix goes there.

## Testing

- `src/TinaMarkdown.test-d.ts` checks that `content` accepts the CLI
shape with `null` and `undefined`, an array of CLI nodes, and every
`TinaRichTextContent` value. It also checks that `content` rejects a
`string`, so a regression to `any` fails. If you remove either generated
member from the union, its case fails.
- `pnpm exec vitest run` in `packages/@tinacms/astro`: 84 tests pass, no
type errors.
- `pnpm exec tsc --noEmit`: passes.
- On an Astro 7 site with CLI 3.0.0, released `@tinacms/astro` 0.7.0
fails `astro check` with the error above. With this build, `astro check`
passes with the generated body passed through and no cast.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: wicksipedia

.changeset/astro-tinamarkdown-generated-rich-text.md

@@ -0,0 +1,7 @@
+---
+'@tinacms/astro': patch
+---
+
+`<TinaMarkdown>` accepts the rich-text type that `@tinacms/cli` 3 generates. The CLI types rich-text fields as `TinaMarkdownContent` from `tinacms`, and `content` accepted only `TinaRichTextContent`, so passing a field such as `data._body` straight from a query failed `astro check`. Both types describe the same AST, so the rendered output does not change.
+
+To type a component that wraps `<TinaMarkdown>`, use `TinaMarkdownProps['content']` from `@tinacms/astro/types`.

packages/@tinacms/astro/README.md

@@ -76,7 +76,7 @@ Trade-off: a page that uses `<TinaIsland>` carries that one-line inline bootstra
 | `@tinacms/astro/TinaMarkdown.astro` | `<TinaMarkdown content components />` — rich-text renderer. Import from this subpath so Astro's check sees a real `.astro` component (the bare-package default resolves through the types condition to a placeholder). |
 | `@tinacms/astro/integration` | `tina()` integration — auto-wires the middleware and stages the static `/admin/bridge.js` asset so `requestWithMetadata()` works without you threading `Astro.request` or writing wiring components |
 | `@tinacms/astro/TinaIsland.astro` | `<TinaIsland name wrapper params [primary] />` — marker wrapper for an editable region; pass `primary` on the page's main region so the editor opens that form instead of the "Referenced Files" list |
-| `@tinacms/astro/types` | `TinaRichTextContent`, `CustomComponentsMap`, `TinaRichTextNode`, `MdxElement`, `TextElement` |
+| `@tinacms/astro/types` | `TinaRichTextContent`, `TinaMarkdownProps`, `CustomComponentsMap`, `TinaRichTextNode`, `MdxElement`, `TextElement` |
 | `@tinacms/astro/sanitize` | `sanitizeHref` / `sanitizeImageSrc` for CMS-supplied URLs |
 | `@tinacms/astro/bridge` | `init`, `refreshForms`, and the rest of `@tinacms/bridge` |
 | `@tinacms/astro/tina-field` | `tinaField()` helper |

packages/@tinacms/astro/src/TinaMarkdown.astro

@@ -18,19 +18,14 @@ export { requestWithMetadata } from './data';
 export { tinaField } from './tina-field';
 
 import Node from './Node.astro';
-import type { CustomComponentsMap, TinaRichTextContent } from './types';
+import type { TinaMarkdownProps, TinaRichTextNode } from './types';
 
-interface Props {
-  content: TinaRichTextContent;
-  components?: CustomComponentsMap;
-}
+type Props = TinaMarkdownProps;
 
 const { content, components = {} } = Astro.props;
 
-const nodes = !content
-  ? []
-  : Array.isArray(content)
-    ? content
-    : (content.children ?? []);
+const nodes = (
+  !content ? [] : Array.isArray(content) ? content : (content.children ?? [])
+) as TinaRichTextNode[];
 ---
 {nodes.map((node) => <Node node={node} components={components} />)}

packages/@tinacms/astro/src/TinaMarkdown.test-d.ts

@@ -0,0 +1,28 @@
+import { describe, expectTypeOf, it } from 'vitest';
+import type { TinaMarkdownProps, TinaRichTextContent } from './types';
+
+// `TinaMarkdownContent` from `tinacms/dist/rich-text`, which `@tinacms/cli`
+// writes into the generated client types for every rich-text field.
+type CliRichText = { type: string; children: CliRichText[] };
+
+describe('TinaMarkdownProps content', () => {
+  it('accepts an optional rich-text field from the generated client', () => {
+    expectTypeOf<CliRichText | null | undefined>().toExtend<
+      TinaMarkdownProps['content']
+    >();
+  });
+
+  it('accepts the children of a generated rich-text field', () => {
+    expectTypeOf<CliRichText[]>().toExtend<TinaMarkdownProps['content']>();
+  });
+
+  it('accepts the Astro rich-text types', () => {
+    expectTypeOf<TinaRichTextContent>().toExtend<
+      TinaMarkdownProps['content']
+    >();
+  });
+
+  it('does not accept values that are not rich text', () => {
+    expectTypeOf<string>().not.toExtend<TinaMarkdownProps['content']>();
+  });
+});

packages/@tinacms/astro/src/index.ts

@@ -10,7 +10,7 @@
  * throws with a clear redirect if someone reaches it.
  */
 import type { AstroComponentFactory } from 'astro/runtime/server/index.js';
-import type { CustomComponentsMap, TinaRichTextContent } from './types';
+import type { TinaMarkdownProps } from './types';
 
 export { requestWithMetadata, type QueryResult } from './data';
 export { tinaField } from './tina-field';
@@ -19,6 +19,7 @@ export type {
   CustomComponentsMap,
   MdxElement,
   TextElement,
+  TinaMarkdownProps,
   TinaRichTextContent,
   TinaRichTextNode,
   TinaRichTextRoot,
@@ -37,10 +38,7 @@ export type {
  * component AND offer prop completions / type errors at the call site.
  */
 type TinaMarkdownComponent = AstroComponentFactory & {
-  (props: {
-    content: TinaRichTextContent;
-    components?: CustomComponentsMap;
-  }): unknown;
+  (props: TinaMarkdownProps): unknown;
 };
 
 const TinaMarkdownPlaceholder = (() => {

packages/@tinacms/astro/src/types.ts

@@ -143,6 +143,24 @@ export type TinaRichTextContent =
   | null
   | undefined;
 
+/**
+ * The type `@tinacms/cli` generates for a rich-text field. It is the same AST
+ * as `TinaRichTextContent`, but each `type` is a `string`, not a literal.
+ * Keep in sync with `TinaMarkdownContent` in `tinacms`.
+ */
+type GeneratedRichTextContent = {
+  type: string;
+  children: GeneratedRichTextContent[];
+};
+
+export interface TinaMarkdownProps {
+  content:
+    | TinaRichTextContent
+    | GeneratedRichTextContent
+    | GeneratedRichTextContent[];
+  components?: CustomComponentsMap;
+}
+
 /**
  * An Astro (or framework) component that accepts props `P`. Astro's language
  * server types an imported `.astro` component as `(props: Props) => any`, so