Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
106 lines (81 loc) · 2.24 KB

CONTRIBUTING.md

File metadata and controls

106 lines (81 loc) · 2.24 KB

Contributing

Thanks for contributing to @howlabs/openstream.

This repository is currently a small TypeScript library, not a monorepo. Contributions should stay aligned with the actual scope of the codebase.

Development Setup

Prerequisites

  • Node.js >= 18
  • npm
  • Git

Initial setup

git clone https://github.com/stream-ai/@howlabs/openstream.git
cd @howlabs/openstream
npm install
npm run test
npm run build
npm run typecheck

Available Commands

npm run build
npm run test
npm run test:watch
npm run test:coverage
npm run typecheck

Project Structure

@howlabs/openstream/
├── src/
│   ├── builder.ts
│   ├── engine.ts
│   ├── types.ts
│   ├── errors.ts
│   ├── costs.ts
│   ├── edge.ts
│   ├── providers/
│   └── __tests__/
├── README.md
├── ARCHITECTURE.md
├── ROADMAP.md
└── package.json

Contribution Guidelines

  • keep changes scoped and concrete
  • update documentation when behavior changes
  • do not add public claims for features that are not implemented
  • prefer small extensions that fit the current architecture
  • discuss major scope changes before implementation

Good Contribution Areas

  • improve test coverage
  • improve error handling
  • add provider contract tests
  • improve OpenAI provider behavior
  • improve docs and examples
  • add one focused provider that fits the existing abstraction
  • add a small middleware that does not expand project scope dramatically

Avoid For Now

Unless discussed first, avoid opening large efforts around:

  • offline sync systems
  • CRDT layers
  • monorepo restructuring
  • broad package ecosystem work
  • platform-matrix claims without implementation

Coding Standards

  • use strict TypeScript
  • prefer explicit names over clever abstractions
  • keep public APIs small
  • prefer composition over inheritance
  • write tests for behavior, not just structure

Pull Requests

Before opening a PR:

  • tests updated where needed
  • docs updated where needed
  • no unsupported feature claims introduced
  • npm run typecheck passes
  • npm run build passes

PRs should explain:

  • what changed
  • why it changed
  • whether public behavior changed
  • whether docs were updated