|
| 1 | +# Contributing |
| 2 | + |
| 3 | +Thanks for helping improve `@api-wrappers/igdb-wrapper`. The best changes keep |
| 4 | +the package focused on its core value: a typed, fluent IGDB client that reduces |
| 5 | +raw APICalypse string handling without removing escape hatches. |
| 6 | + |
| 7 | +## Setup |
| 8 | + |
| 9 | +```bash |
| 10 | +bun install |
| 11 | +``` |
| 12 | + |
| 13 | +Use Node.js 18+ or Bun with the repo's checked-in lockfile. Keep dependency |
| 14 | +changes small and explain why they are needed. |
| 15 | + |
| 16 | +## Development Commands |
| 17 | + |
| 18 | +```bash |
| 19 | +bun run typecheck |
| 20 | +bun run test |
| 21 | +bun run build |
| 22 | +bun run check |
| 23 | +``` |
| 24 | + |
| 25 | +Before opening a release-oriented PR, also run: |
| 26 | + |
| 27 | +```bash |
| 28 | +bun run verify |
| 29 | +``` |
| 30 | + |
| 31 | +## Code Style |
| 32 | + |
| 33 | +- Keep TypeScript strict. |
| 34 | +- Do not use `any`; prefer `unknown`, generics, or narrower types. |
| 35 | +- Prefer `Array<Type>` over `Type[]` when adding or changing type annotations. |
| 36 | +- Prefer const functions for new helpers unless a class method or declaration is |
| 37 | + required by the surrounding API. |
| 38 | +- Keep public API changes minimal and documented. |
| 39 | +- Keep raw APICalypse examples accurate when a typed builder feature does not |
| 40 | + exist yet. |
| 41 | + |
| 42 | +## Documentation Expectations |
| 43 | + |
| 44 | +Docs are part of the product. If a change affects user-facing behavior, update |
| 45 | +the relevant docs in `README.md`, `docs/`, or `examples/`. |
| 46 | + |
| 47 | +When documenting query-builder examples: |
| 48 | + |
| 49 | +- Inspect the source before writing new syntax. |
| 50 | +- Use actual methods exported by the package. |
| 51 | +- Mention raw escape hatches when the current API is string-based. |
| 52 | +- Add a roadmap item instead of implying unsupported typed behavior exists. |
| 53 | + |
| 54 | +## Pull Requests |
| 55 | + |
| 56 | +Small PRs are easier to review. A good PR includes: |
| 57 | + |
| 58 | +- A clear summary of the user problem. |
| 59 | +- The exact behavior change. |
| 60 | +- Tests or a note explaining why tests were not added. |
| 61 | +- Validation output for typecheck, tests, build, and prepublish checks when |
| 62 | + relevant. |
| 63 | + |
| 64 | +## Releases |
| 65 | + |
| 66 | +See [docs/release-readiness.md](./docs/release-readiness.md) before publishing. |
0 commit comments