Thanks for helping out. This page tells you how.
Code is not the only way to contribute. Fixing typos, improving docs, triaging issues, and reviewing pull requests all count.
You need Bun 1+.
git clone https://github.com/1gr14/flat.git
cd flat
bun installbun run test # run tests
bun run types # type-check
bun run lint # lint and auto-fix
bun run build # build to dist/
bun run smoke # smoke-test the built packageRun bun run test, bun run types, and bun run lint before you push.
- Search existing issues first, including closed ones.
- For a bug, include a minimal example that reproduces it. A runnable link is best.
- For a feature, explain the problem before the solution.
- For large or breaking changes, open an issue first. Don't write a big PR that might get rejected.
- One PR, one topic. No unrelated changes.
- Match the existing code style.
- Add or update tests for your change. When you change public types, add type
tests with
expectTypeOffrombun:test(checked bytsc). - Work on a branch, not
main, and open the PR againstmain. CI runs the full gate (types, lint, tests, smoke) on every PR — that green check is required to merge. Releases are maintainer-only: the maintainer bumps withbun run releaseand pushesmain, and CI publishes and tags once that run is green. You never bump versions or tag in a PR. - Keep "Allow edits from maintainers" checked.
We use Conventional Commits (checked by
commitlint) — they keep history readable. Versions are not derived from
commits: the maintainer picks the next version explicitly with
bun run release, and changelog notes go under ## Unreleased in
CHANGELOG.md.
feat: add arrayIndexes option
fix: handle repeated keys in parse
docs: clarify FormData example
Mark a breaking change with !:
feat!: make arrayIndexes false by default
That's it. Open the PR and we'll take it from there.