Skip to content

CLAUDE.md

Latest commit

 

History

History
65 lines (55 loc) · 3.03 KB

CLAUDE.md

File metadata and controls

65 lines (55 loc) · 3.03 KB

CLAUDE.md

Build Commands

  • Build All: npm run build
  • Documentation Build: npm run docs:build

Test Commands

  • Run All Tests: npm run test
  • Fast Tests (Parallel): npm run test:fast
  • Fast Memory Tests: npm run test:fast:memory
  • Node Tests: npm run test:node
  • Browser Tests: npm run test:browser
  • Performance Tests: npm run test:performance
  • Lint: npm run lint
  • Lint Fix: npm run lint:fix
  • Check Types: npm run check-types

Development Scripts

  • Unwatch Tests: npm run dev
  • Watch Example: npm run dev:example
  • Generate Error Messages: npm run generate:error-messages
  • Start Docs Server: npm run docs:serve

Code Style & Patterns

  • Language: TypeScript
  • Database: RxDB (local-first, NoSQL)
  • State Management: Reactive (RxJS Observables)
  • Formatting: Uses ESLint. Run npm run lint to check and npm run lint:fix to auto-fix.
  • Imports: Uses ES modules (import/export).
  • Paths: Source code in src/, tests in test/, documentation in docs-src/.
  • TypeScript: Do not use enums. Prefer types instead of interfaces.
  • Errors: Do not use throw new Error(). Use throw newRxError() or throw newRxTypeError() instead to reduce build size and do not include full error messages in production builds. Use the error codes from src/rx-error.ts and add new error codes if needed like PL1, PL2. Example: throw newRxError('PL1', { plugin });

Development Workflow

# 1. Make changes

# 2. Build
npm run build

# 3. Run tests
npm run test:fast:memory

# 4. Run lint
npm run lint

# 5. Check TypeScript types
npm run check-types

Documentation Style

  • SHOULD use clear, simple language.
  • SHOULD use data and examples to support claims when possible.
  • SHOULD be informative.
  • SHOULD focus on practical, actionable insights.
  • AVOID using em dashes (–) anywhere.
  • AVOID constructions like "not just this, but also this".
  • AVOID metaphors and cliches.
  • AVOID generalizations.
  • AVOID upfront warnings or notes, just the output requested.
  • AVOID rhetorical questions.
  • AVOID specific words like: very, really, literally, actually, certainly, probably, basically, delve, embark, enlightening, esteemed, shed light, craft, creative, imagine, realm, game-changer, unlock, discover, skyrocket, abyss, not alone, in a world where, revolutionize, disruptive, utilize, utilizing, dive deep, tapestry, illuminate, unveil, pivotal, intricate, elucidate, hence, furthermore, realm, however, harness, exciting, groundbreaking, cutting-edge, remarkable, it remains to be seen, glimpse into, navigating, landscape, stark, testament, in summary, in conclusion, moreover, boost, skyrocket, opened up, powerful, inquiries, ever-evolving.
  • Review your response and ensure no em dashes.
  • MUST format FAQ sections using HTML <details> and <summary> tags. Ensure there is an empty line before and after the inner markdown content so it parses correctly.
  • SHOULD try to use components from the docs-src/src/components folder when writing docs.