---
name: packages-documentation
description: Write, update, and format documentation for @data-client public APIs - API reference (Docusaurus/MDX), README files, JSDoc/TSDoc docstrings, usage examples, migration guides, deprecation notices, changelog entries. Use when changing exported APIs (docs must update in the same PR), writing new package docs, or updating the dataclient.io site.
license: Apache 2.0
---
# Package Documentation Writing Guidelines

This guide covers how to write and format documentation for public library interfaces.

## Documentation Structure

The `/docs` folder is organized by package:
- `docs/core/` - Documentation for `@data-client/core` and `@data-client/react`
- `docs/rest/` - Documentation for `@data-client/rest`
- `docs/graphql/` - Documentation for `@data-client/graphql`

Each package documentation has subdirectories:
- `api/` - API reference documentation (one file per public class/function/hook)
- `guides/` - How-to guides and tutorials
- `concepts/` - Conceptual documentation
- `getting-started/` - Getting started guides

## Documentation File Naming

API documentation files should match the exported name:
- `useSuspense.ts` → `docs/core/api/useSuspense.md`
- `RestEndpoint.js` → `docs/rest/api/RestEndpoint.md`
- `Controller.ts` → `docs/core/api/Controller.md`
- `Entity.ts` → `docs/rest/api/Entity.md` (or `docs/core/api/Entity.md`)

## Documentation Format

All API documentation files should include:

1. **Frontmatter** with metadata:
```markdown
---
title: API Name
sidebar_label: Display Name
---
```

2. **Description** - What the API does

3. **Usage examples** - Code examples showing how to use it

4. **Parameters/Options** - Document all parameters, options, and return types

5. **Type information** - TypeScript types and examples

6. **Related APIs** - Links to related documentation

## Finding the Right Documentation File

1. **Identify the package**: Check which package the code belongs to (`packages/core`, `packages/rest`, etc.)
2. **Check exports**: Look at the package's `index.ts` or main entry point to see what's exported
3. **Match the name**: Find the corresponding file in `docs/{package}/api/`
4. **Check guides**: If it's a workflow change, also check `docs/{package}/guides/`

## Examples

### Example 1: Adding a new hook
- **File**: `packages/react/src/hooks/useNewFeature.ts`
- **Action**: Create `docs/core/api/useNewFeature.md` with usage examples and API reference

### Example 2: Changing a method signature
- **File**: `packages/rest/src/RestEndpoint.js` (changing `extend()` method)
- **Action**: Update `docs/rest/api/RestEndpoint.md` with new signature, migration notes, and updated examples

### Example 3: Deprecating an API
- **File**: `packages/core/src/SomeClass.ts` (deprecating `oldMethod()`)
- **Action**: 
  - Update `docs/core/api/SomeClass.md` with deprecation notice
  - Document the replacement API
  - Add migration guide if needed

### Example 4: Adding a new option
- **File**: `packages/rest/src/RestEndpoint.js` (adding `newOption` parameter)
- **Action**: Update `docs/rest/api/RestEndpoint.md` to document the new option with examples

## Checklist

Before completing changes to public APIs in `/packages`:

- [ ] Identified all affected public APIs (exports from package entry points)
- [ ] Located or created corresponding documentation files in `/docs/{package}/api/`
- [ ] Updated API reference documentation with changes
- [ ] Added/updated code examples
- [ ] Updated related guides if workflow changed
- [ ] Added migration notes for breaking changes
- [ ] Updated TypeScript examples in documentation
- [ ] Verified documentation builds correctly (if applicable)

## Important Notes

- **Public APIs** are anything exported from the package's main entry point (typically `index.ts` or `src/index.ts`)
- **Internal/private APIs** (prefixed with `_`, not exported, or marked as `@internal`) don't require documentation updates
- When in doubt, **err on the side of documenting** - it's better to have extra documentation than missing documentation
- Documentation should be updated **in the same commit or PR** as the code changes