---
name: repo-website-api-update
description: Update existing API documentation when Formisch source code changes. Use when function signatures, types, interfaces, or JSDoc comments change in the library source.
metadata:
author: formisch
version: '1.0'
---
# Updating API Documentation
API documentation must stay synchronized with source code. When functions, types, or interfaces change in the Formisch packages, update the corresponding documentation.
**Key Principle**: Source code is the single source of truth. Documentation must never deviate from what's actually implemented.
## When to Update
Update documentation when:
- **Function signatures change** - New/removed parameters, type changes, generic constraints
- **Interfaces change** - New/modified/removed properties
- **JSDoc comments change** - Descriptions, param docs, hints
- **Behavior changes** - Validation logic, error messages, defaults
- **Deprecations or renames** - Functions deprecated or renamed
**Do NOT update when**:
- Only internal implementation changes
- Private/internal functions change
- Test files change
- Non-JSDoc comments change
## Update Process
### Step 1: Understand the Changes
Compare source code changes:
```bash
git diff HEAD~1 packages/core/src/path/to/file.ts
```
Categorize changes:
- **Breaking changes**: Signature changes, removed parameters
- **Additions**: New parameters, overloads, properties
- **Documentation changes**: JSDoc updates
- **Behavioral changes**: Logic affecting usage
### Step 2: Find Affected Documentation
Locate files to update:
```
/website/src/routes/(docs)/{framework}/api/{category}/{ApiName}/
├── index.mdx
└── properties.ts
```
### Step 3: Update properties.ts
Ensure types match new source code:
```typescript
// If generic constraint changed from:
TInput
// To:
TInput extends string | number
// Update properties.ts:
TInput: {
modifier: 'extends',
type: {
type: 'union',
options: ['string', 'number'],
},
},
```
### Step 4: Update index.mdx
1. **Front matter**: Update `source` path if file moved
2. **Function signature**: Match new signature exactly
3. **Generics section**: Add/remove/update generics
4. **Parameters section**: Add/remove/update parameters
5. **Explanation**: Update if behavior changed
6. **Examples**: Update to use new API correctly
7. **Related section**: Update cross-references
### Step 5: Update Related Files
- **Type documentation**: If interfaces changed
- **menu.md**: If function renamed/moved
- **Guide files**: If usage patterns changed
## Common Change Scenarios
### Adding a Parameter
**Source change**:
```typescript
// Before
export function validate(form: FormStore): void;
// After (added config)
export function validate(form: FormStore, config?: ValidateConfig): void;
```
**properties.ts update**:
```typescript
// Add new parameter
config: {
type: {
type: 'union',
options: [
{ type: 'custom', name: 'ValidateConfig', href: '../ValidateConfig/' },
'undefined',
],
},
},
```
**index.mdx update**:
- Update function signature
- Add to Parameters section
- Update Explanation to mention new parameter
- Add examples using new parameter
### Removing a Parameter (Breaking)
1. Remove from properties.ts
2. Update function signature in index.mdx
3. Remove from Parameters section
4. Update all examples
5. Consider adding migration note
### Changing Types
**Source change**:
```typescript
// Before
TRequirement extends number
// After
TRequirement extends number | string
```
**properties.ts update**:
```typescript
TRequirement: {
modifier: 'extends',
type: {
type: 'union',
options: ['number', 'string'],
},
},
```
### Adding Interface Properties
Update type documentation:
```typescript
// In properties.ts, add new property
received: {
type: 'string',
},
```
Update index.mdx Definition section:
```mdx
- `StringIssue`
- `kind`
- `type`
- `received`
```
### Function Renamed
1. Rename folder: `mv /api/oldName /api/newName`
2. Update properties.ts references
3. Update all occurrences in index.mdx
4. Update menu.md (maintain alphabetical order)
5. Update guide files
6. Update related API docs that reference this function
### Deprecation
Add deprecation notice after description:
```mdx
# oldFunction
Creates a form store.
> **⚠️ Deprecated**: Use `newFunction` instead. This function will be removed in v2.0.
```
## Link Updates
### Cross-Package Links (Use Absolute)
```typescript
// ✅ Correct
href: '/core/api/Schema/';
// ❌ Wrong - relative won't work across packages
href: '../../../core/api/Schema/';
```
### Qwik Routing (Exclude Parentheses)
```typescript
// ✅ Correct
href: '../FormStore/';
// ❌ Wrong - Qwik ignores (types) segment
href: '../(types)/FormStore/';
```
## Verification Checklist
### Source Code Accuracy
- [ ] All generic constraints match source exactly
- [ ] All parameter types match source exactly
- [ ] Return type matches source exactly
- [ ] Function signature identical to source
### Type Links
- [ ] All `href` links point to existing documentation
- [ ] Generic references use correct names
- [ ] No broken links to removed types
### Examples
- [ ] All examples use updated API correctly
- [ ] Examples compile with new signature
- [ ] New features demonstrated in examples
### Consistency
- [ ] Tone and style match existing docs
- [ ] Naming conventions maintained
- [ ] Related section accurate
### Cleanup
- [ ] All properties in properties.ts are actually used
- [ ] Remove any unused properties
- [ ] No orphaned references
## Quick Reference
### Properties.ts Pattern for Optional Parameter
```typescript
// Optional = union with undefined
config: {
type: {
type: 'union',
options: [
{ type: 'custom', name: 'Config', href: '../Config/' },
'undefined',
],
},
},
```
### Multiple Overloads in Signature
```mdx
\`\`\`ts
const result = fn(form);
const result = fn(form, config);
\`\`\`
```
### Type Reference Rules
Reference generic parameter names, not base types:
```typescript
// ✅ Correct - use parameter name
generics: [{ type: 'custom', name: 'TFieldPath' }];
// ❌ Wrong - using constraint type
generics: [{ type: 'custom', name: 'RequiredPath' }];
```