Skip to content

Commit 558c517

Browse files
committed
add maintainer documentation for markdown features and redirects
1 parent 642c668 commit 558c517

File tree

1 file changed

+233
-0
lines changed

1 file changed

+233
-0
lines changed

docs-info.md

Lines changed: 233 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,233 @@
1+
# Maintainer Documentation Guide
2+
3+
This page covers the markdown features supported in TanStack docs and the preferred workflow for future redirects.
4+
5+
## Redirects
6+
7+
For new page moves or consolidations, keep the canonical page and list old URLs in frontmatter with `redirect_from`.
8+
9+
```yaml
10+
---
11+
title: Overview
12+
redirect_from:
13+
- /framework/react/overview
14+
- /framework/solid/overview
15+
---
16+
```
17+
18+
In the example above, old framework-specific URLs will redirect to the shared `/overview` page without needing to add a new entry to the central redirect files in the `tanstack.com` repo.
19+
20+
## Supported markdown
21+
22+
Docs support normal GitHub-flavored markdown, including:
23+
24+
- headings
25+
- links
26+
- lists
27+
- tables
28+
- fenced code blocks
29+
- images
30+
- blockquotes
31+
- task lists
32+
33+
## Callouts
34+
35+
GitHub-style alerts are supported. For a customized title, for example to replace `Note` with something else, you can use the syntax `> [!TYPE] Title`:
36+
37+
```md
38+
> [!NOTE] Custom title
39+
> Use `redirect_from` on the canonical page when docs are moved.
40+
41+
> [!TIP]
42+
> Prefer absolute paths like `/framework/react/overview`.
43+
```
44+
45+
## Code Blocks
46+
47+
Fenced code blocks are supported with language identifiers for syntax highlighting. You can also add metadata like `title="..."` for file tabs.
48+
49+
````md
50+
```tsx title="app.tsx"
51+
export function App() {
52+
return <div>Hello</div>
53+
}
54+
``
55+
````
56+
57+
58+
## Tabs component
59+
60+
The tabs component lets you group content into tabbed sections. It supports multiple variants, including file tabs and package manager tabs.
61+
62+
### File tabs
63+
64+
Use `variant="files"` when the block should render code examples as file tabs. It scans consecutive code blocks, extracts language, title, and content, and uses that to build `file-tab` data. Titles come from code-block metadata such as `title="..."` or will default to the language name if not provided.
65+
66+
````md
67+
<!-- ::start:tabs variant="files" -->
68+
69+
```tsx file="app.tsx"
70+
export function App() {
71+
return <div>Hello</div>
72+
}
73+
```
74+
75+
```css file="styles.css"
76+
body {
77+
color: tomato;
78+
}
79+
```
80+
81+
<!-- ::end:tabs -->
82+
````
83+
84+
### What matters
85+
86+
- use fenced code blocks
87+
- add `title="..."` if you want meaningful file tab labels
88+
- language comes from the code fence language
89+
- code text is extracted from the `<code>` node content
90+
91+
92+
### Package manager tabs
93+
94+
Package-manager tabs are a special `tabs` variant. The parser reads framework lines like `react: ...` or `solid: ...`, groups packages, and later generates package-manager-specific commands.
95+
96+
There are various supported package manager formats, including npm, yarn, pnpm, and bun.
97+
98+
If you're looking to support a multi-line command, you can add multiple instances of the same framework. For example:
99+
100+
```md
101+
<!-- ::start:tabs variant="package-manager" -->
102+
react: <package-1>
103+
react: <package-2>
104+
<!-- ::end:tabs -->
105+
```
106+
107+
This will become:
108+
109+
```bash
110+
npm i <package-1>
111+
npm i <package-2>
112+
```
113+
114+
#### Supported modes
115+
116+
- `install` (default)
117+
- `dev-install`
118+
- `local-install`
119+
- `create`
120+
- `custom` (for custom command templates)
121+
122+
##### Install (default)
123+
124+
```md
125+
<!-- ::start:tabs variant="package-manager" mode="install" -->
126+
react: <package>
127+
solid: <package>
128+
<!-- ::end:tabs -->
129+
```
130+
131+
becomes
132+
133+
```bash
134+
npm i <package>
135+
```
136+
137+
138+
##### Dev install
139+
140+
```md
141+
<!-- ::start:tabs variant="package-manager" mode="dev-install" -->
142+
react: <package>
143+
solid: <package>
144+
<!-- ::end:tabs -->
145+
```
146+
147+
becomes
148+
149+
```bash
150+
npm i -D <package>
151+
```
152+
153+
##### Local install
154+
155+
```md
156+
<!-- ::start:tabs variant="package-manager" mode="local-install" -->
157+
react: <package>
158+
solid: <package>
159+
<!-- ::end:tabs -->
160+
```
161+
162+
becomes
163+
164+
```bash
165+
npx <package> --workspace=./path/to/workspace
166+
```
167+
168+
##### Create
169+
170+
```md
171+
<!-- ::start:tabs variant="package-manager" mode="create" -->
172+
react: <package>
173+
solid: <package>
174+
<!-- ::end:tabs -->
175+
```
176+
177+
becomes
178+
179+
```bash
180+
npm create <package>
181+
```
182+
183+
##### Custom
184+
185+
```md
186+
<!-- ::start:tabs variant="package-manager" mode="custom" -->
187+
react: <command> <package>
188+
solid: <command> <package>
189+
<!-- ::end:tabs -->
190+
```
191+
192+
becomes
193+
194+
```bash
195+
npm <command> <package>
196+
```
197+
198+
## Framework component
199+
200+
Framework blocks let one markdown source contain React, Solid, or other framework-specific content. Internally, the transformer looks for h1 headings inside the framework block and treats each `# Heading` as a framework section boundary. It then stores framework metadata and rewrites the block into separate framework panels.
201+
202+
> **Note**: This should only be used when the majority of the content is the same. If the content is mostly different, it's better to create separate markdown files for each framework and use redirects to point to the canonical page.
203+
204+
````md
205+
<!-- ::start:framework -->
206+
207+
# React
208+
209+
Use the React adapter here.
210+
211+
```tsx
212+
// React code
213+
```
214+
215+
# Solid
216+
217+
Use the Solid adapter here.
218+
219+
```tsx
220+
// Solid Code
221+
```
222+
223+
<!-- ::end:framework -->
224+
````
225+
226+
Each top-level `#` heading becomes a framework panel. Nested headings inside a framework section are preserved for the table of contents.
227+
228+
## Editing notes
229+
230+
- Keep redirects on the surviving page, not on the page being removed.
231+
- Use absolute paths in `redirect_from`.
232+
- Avoid duplicate `redirect_from` values across pages.
233+
- Existing central redirect files still handle older redirects; use frontmatter for new ones going forward.

0 commit comments

Comments
 (0)