|
1 | | -# Contributing |
2 | | - |
3 | | -## Workflow |
4 | | - |
5 | | -1. Create a branch from `main`. |
6 | | -2. Install dependencies and bootstrap the local database: |
7 | | - |
8 | | -```bash |
9 | | -npm install |
10 | | -npm run db:bootstrap:local |
11 | | -``` |
12 | | - |
13 | | -3. Make changes locally. |
14 | | -4. Commit normally. Husky runs the routine local checks for you: |
15 | | - |
16 | | -- on commit: block commits on `main` with a friendly branch-switch reminder |
17 | | -- on commit: staged-file Biome fixes/checks |
18 | | -- on push: generated-file verification, typecheck, and tests |
19 | | - |
20 | | -5. If you want to run the same push-time validation manually before pushing, use: |
21 | | - |
22 | | -```bash |
23 | | -npm run check:prepush |
24 | | -``` |
25 | | - |
26 | | -6. Only run extra checks when the change needs them: |
27 | | - |
28 | | -- run `npm run build` if the change affects deployment/build behavior or you want an extra production sanity check |
29 | | -- run `npm run test:e2e` if you changed user-facing flows or browser interactions |
30 | | -- run `npm run lint` manually if you want the compact full-repo Biome pass outside the staged-file hook |
31 | | -- run `npm run lint:full` if you want Biome's detailed inline diagnostics and formatter diffs |
32 | | - |
33 | | -7. Open a pull request. |
34 | | -8. Wait for CI to pass. |
35 | | -9. Review the preview deployment if one is enabled for the repository. |
36 | | -10. Merge to `main`. |
37 | | - |
38 | | -Merges to `main` are intended to trigger a production deploy. |
39 | | - |
40 | | -## Day-to-day local checks |
41 | | - |
42 | | -Most contributors should not need to run `format`, `lint`, `test`, and `typecheck` manually before every commit. |
43 | | - |
44 | | -Use this default path instead: |
45 | | - |
46 | | -```bash |
47 | | -git add <files> |
48 | | -git commit |
49 | | -git push |
50 | | -``` |
51 | | - |
52 | | -If a hook fails: |
53 | | - |
54 | | -- fix the reported issue and retry |
55 | | -- or run `npm run check:prepush` yourself to reproduce the push-time gate before pushing again |
56 | | -- if the branch guard blocks a commit on `main`, switch to a feature branch before committing |
57 | | - |
58 | | -## Releases |
59 | | - |
60 | | -- Keep [CHANGELOG.md](CHANGELOG.md) and [package.json](package.json) in sync when preparing a release PR. |
61 | | -- Use `0.x.x` for normal minor/patch releases while the project is still pre-`1.0`. |
62 | | -- If the release is a major milestone or materially changes the product scope, bump the middle digit such as `0.2.0`. |
63 | | -- Otherwise, use a patch release such as `0.1.1`. |
64 | | -- Ask explicitly which release level is intended if it is not obvious from the scope of the work. |
65 | | - |
66 | | -## Local development |
67 | | - |
68 | | -Start here: |
69 | | - |
| 1 | +# Contributing |
| 2 | + |
| 3 | +## Workflow |
| 4 | + |
| 5 | +1. Branch from `main`. |
| 6 | +2. Install dependencies and bootstrap local data: |
| 7 | + |
| 8 | +```bash |
| 9 | +npm install |
| 10 | +npm run db:bootstrap:local |
| 11 | +``` |
| 12 | + |
| 13 | +3. Make the change. |
| 14 | +4. Commit and push normally: |
| 15 | + |
| 16 | +```bash |
| 17 | +git add <files> |
| 18 | +git commit |
| 19 | +git push |
| 20 | +``` |
| 21 | + |
| 22 | +The repo hooks handle the default checks: |
| 23 | + |
| 24 | +- `pre-commit`: blocks commits on `main` and runs staged-file Biome fixes/checks |
| 25 | +- `pre-push`: runs generated-file checks, typecheck, and tests |
| 26 | + |
| 27 | +If you want the push-time gate before pushing, run: |
| 28 | + |
| 29 | +```bash |
| 30 | +npm run check:prepush |
| 31 | +``` |
| 32 | + |
| 33 | +Run extra checks only when the change needs them: |
| 34 | + |
| 35 | +- `npm run build` for deployment-sensitive changes |
| 36 | +- `npm run test:e2e` for browser flows |
| 37 | +- `npm run lint` or `npm run lint:full` for a full-repo Biome pass |
| 38 | +- `npm run check:ship` for the full pre-PR ship flow |
| 39 | +- `npm run build:extension:package` when the change affects the standalone Twitch panel artifact |
| 40 | + |
| 41 | +## Codex Ship Flow |
| 42 | + |
| 43 | +Use this trigger when you want Codex to run the full branch shipping workflow: |
| 44 | + |
| 45 | +```text |
| 46 | +Use $request-bot-ship to ship this branch. |
| 47 | +``` |
| 48 | + |
| 49 | +That flow runs the repo ship checks, packages the Twitch panel artifact when the changed files affect it, stages and commits the branch, pushes it, opens the PR, waits for checks, and merges only after checks pass. |
| 50 | + |
| 51 | +## Commit Messages |
| 52 | + |
| 53 | +Use this format: |
| 54 | + |
| 55 | +- imperative present tense |
| 56 | +- one short subject line |
| 57 | +- no trailing period |
| 58 | +- summarize the primary outcome |
| 59 | + |
| 60 | +Examples: |
| 61 | + |
| 62 | +- `Refine ship workflow and docs` |
| 63 | +- `Add panel packaging and release checks` |
| 64 | + |
| 65 | +## Pull Requests |
| 66 | + |
| 67 | +- Keep the scope focused. |
| 68 | +- Add or update tests when behavior changes. |
| 69 | +- Update docs in the same PR when the workflow, setup, deploy path, or product behavior changes. |
| 70 | +- Call out migrations, Twitch auth changes, EventSub changes, queue mutations, or Cloudflare binding changes in the PR description. |
| 71 | + |
| 72 | +## Database Changes |
| 73 | + |
| 74 | +- Update [schema.ts](src/lib/db/schema.ts) |
| 75 | +- Add the matching SQL migration under [drizzle](drizzle) |
| 76 | +- Run: |
| 77 | + |
| 78 | +```bash |
| 79 | +npm run db:migrate |
| 80 | +``` |
| 81 | + |
| 82 | +Do not leave code that expects a schema change without a checked-in migration. |
| 83 | + |
| 84 | +## Releases |
| 85 | + |
| 86 | +- Keep [CHANGELOG.md](CHANGELOG.md) and [package.json](package.json) aligned when preparing a release. |
| 87 | +- Use `0.x.x` while the app is still pre-`1.0`. |
| 88 | +- Use a patch release for routine shipped work. |
| 89 | +- Use a minor release when the shipped product scope expands materially. |
| 90 | + |
| 91 | +## Start Here |
| 92 | + |
70 | 93 | - [README.md](README.md) |
71 | 94 | - [docs/local-development.md](docs/local-development.md) |
72 | | - |
73 | | -## Database changes |
74 | | - |
75 | | -- Put schema changes in [src/lib/db/schema.ts](src/lib/db/schema.ts) |
76 | | -- Generate or add the matching SQL migration in [drizzle](drizzle) |
77 | | -- Run `npm run db:migrate` |
78 | | -- Do not leave the code expecting a schema change that is not represented by a migration |
79 | | - |
80 | | -The app checks the latest applied migration at runtime and fails early if the local database is behind. |
81 | | - |
82 | | -## Pull request expectations |
83 | | - |
84 | | -- Keep changes focused. |
85 | | -- Include tests when you change behavior. |
86 | | -- Do not rely on CI as your first feedback loop. Use the commit/push hooks, or run `npm run check:prepush` manually before opening the PR. |
87 | | -- If a change affects Twitch auth, EventSub, playlist mutations, or migrations, call that out in the PR description. |
88 | | -- If a change affects deployment or Cloudflare bindings, update the docs in the same PR. |
89 | | - |
90 | | -## Before enabling open contributions |
91 | | - |
92 | | -Recommended repository settings: |
93 | | - |
94 | | -- protect `main` |
95 | | -- require pull requests for merge |
96 | | -- require the CI workflow to pass |
97 | | -- require at least one review before merge |
98 | | -- restrict direct pushes to `main` |
| 95 | +- [docs/deployment-workflow.md](docs/deployment-workflow.md) |
0 commit comments