|
| 1 | +# Contributing to Flatbread |
| 2 | + |
| 3 | +Thanks for your interest in contributing! This guide covers local development and the release process (bumping versions and publishing packages). |
| 4 | + |
| 5 | +## Prerequisites |
| 6 | + |
| 7 | +- Node 16+ |
| 8 | +- pnpm |
| 9 | +- Clean git working tree (commit/stash your work first) |
| 10 | + |
| 11 | +## Local development |
| 12 | + |
| 13 | +- Install dependencies: `pnpm -w i` |
| 14 | +- Build all packages: `pnpm build` |
| 15 | +- Run dev across packages: `pnpm dev` |
| 16 | +- Work in examples (Next.js preferred): `pnpm play` |
| 17 | + |
| 18 | +## Working on a package |
| 19 | + |
| 20 | +Open another terminal tab while keeping the dev server running. |
| 21 | + |
| 22 | +- Option 1 (preferred): use the Next.js example as a demo project |
| 23 | + |
| 24 | + - Work in the full context of a Flatbread instance as an end-user would, while tinkering with `packages/*` internals. |
| 25 | + - Command: `pnpm play` (starts the Next.js example) |
| 26 | + - Good when you want to test without creating per-package temporary clutter. |
| 27 | + |
| 28 | +- Option 2: scope to a specific package |
| 29 | + - Change directory: `cd packages/<package>` |
| 30 | + - Run the package entry (ensure built first): `node dist/index.mjs` |
| 31 | + - Tip: you may need to seed with `pnpm build` once if types/builds are missing. |
| 32 | + |
| 33 | +### Build for production |
| 34 | + |
| 35 | +Uses `tsup` to build each package in the monorepo (excluding integration examples): |
| 36 | + |
| 37 | +```bash |
| 38 | +pnpm build |
| 39 | +``` |
| 40 | + |
| 41 | +## Pull Requests and Tests |
| 42 | + |
| 43 | +- Keep PRs small and focused; link related issues. |
| 44 | +- Ensure CI passes all checks. |
| 45 | +- Add test coverage for both positive and negative cases: |
| 46 | + - Positive: expected success paths and typical inputs. |
| 47 | + - Negative: invalid inputs, edge cases, and error handling/failure modes. |
| 48 | +- Place tests in the relevant package and use its existing runner/config (Vitest in most packages; some legacy tests use Ava). |
| 49 | +- Helpful commands: |
| 50 | + - All packages: `pnpm -r test` |
| 51 | + - Single package: `pnpm -F <package-name> test` |
| 52 | + - Watch (where supported): `pnpm -F <package-name> test:watch` |
| 53 | + |
| 54 | +## Releasing packages |
| 55 | + |
| 56 | +There are two steps: |
| 57 | + |
| 58 | +1. Bump versions where there are changes |
| 59 | +2. Publish the changed packages |
| 60 | + |
| 61 | +### 1) Bump versions only where there are changes |
| 62 | + |
| 63 | +Use the interactive bump script: |
| 64 | + |
| 65 | +```bash |
| 66 | +pnpm bump |
| 67 | +``` |
| 68 | + |
| 69 | +What the script does: |
| 70 | + |
| 71 | +- Detects changes since last publish per package by: |
| 72 | + - Querying npm for the package's latest published version and its publish time |
| 73 | + - Comparing git commits in `packages/<name>` since that time |
| 74 | + - Ignoring commits that only change the `version` field in `package.json` |
| 75 | + - Skipping packages that are not yet published on npm |
| 76 | +- Preselects only changed packages for you to bump |
| 77 | +- Runs `pnpm bumpp --no-commit --no-push --no-tag` in each selected package directory |
| 78 | + |
| 79 | +Notes: |
| 80 | + |
| 81 | +- Commit the version bumps after the script completes. For example: |
| 82 | + |
| 83 | + ```bash |
| 84 | + git add packages/**/package.json |
| 85 | + git commit -m "release: bump versions for changed packages" |
| 86 | + ``` |
| 87 | + |
| 88 | +- Debugging: set `FLATBREAD_BUMP_DEBUG=1` to see detection details |
| 89 | + |
| 90 | + ```bash |
| 91 | + FLATBREAD_BUMP_DEBUG=1 pnpm bump |
| 92 | + ``` |
| 93 | + |
| 94 | +- New (unpublished) packages: these are excluded from the bump prompt. Ensure their `package.json` has the desired starting version before publishing (see below). |
| 95 | + |
| 96 | +### 2) Publish packages |
| 97 | + |
| 98 | +> Note: you must have access permissions on NPM |
| 99 | +
|
| 100 | +Publish all public packages (the script builds first and then attempts to publish each package): |
| 101 | + |
| 102 | +```bash |
| 103 | +pnpm publish:ci |
| 104 | +``` |
| 105 | + |
| 106 | +Details: |
| 107 | + |
| 108 | +- Builds the repo: `pnpm run build` |
| 109 | +- Iterates public packages in `packages/*` and runs: |
| 110 | + |
| 111 | + ```bash |
| 112 | + pnpm publish --access public --no-git-checks |
| 113 | + ``` |
| 114 | + |
| 115 | +- If a package's version was not changed, the publish for that package will error and the script will move on to the next |
| 116 | +- Unpublished packages will be published for the first time |
| 117 | +- Dist-tags (alpha/beta) are currently disabled in the script. If you need them, bump with a pre-release version (`x.y.z-alpha.n`) and add tagging logic in `scripts/publish.ts` |
| 118 | + |
| 119 | +### Post-publish |
| 120 | + |
| 121 | +- Push your commits: |
| 122 | + |
| 123 | + ```bash |
| 124 | + git push |
| 125 | + ``` |
| 126 | + |
| 127 | +- Tag a new release via Github and include a set of changes with Dev Experience in mind |
| 128 | + |
| 129 | +## Troubleshooting |
| 130 | + |
| 131 | +- The bump script shows all packages as changed |
| 132 | + |
| 133 | + - If npm is unreachable, the script may conservatively mark packages as changed |
| 134 | + |
| 135 | +- A package didn’t appear in the bump list |
| 136 | + |
| 137 | + - If the local version is already higher than npm’s latest, it’s considered already bumped |
| 138 | + - Unpublished packages are skipped during bump but will be published during `publish:ci` |
| 139 | + |
| 140 | +- First-time publish of a new package |
| 141 | + - Set an appropriate initial version in `packages/<name>/package.json` |
| 142 | + - Run `pnpm publish:ci` (the script will publish it) |
| 143 | + |
| 144 | +If something’s unclear or you hit an issue, please open an issue or ask in Slack. |
0 commit comments