Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
189 lines (137 loc) · 7.88 KB

CONTRIBUTING.md

File metadata and controls

189 lines (137 loc) · 7.88 KB
Raw

Contributing

Questions

If you have questions about implementation details, help, or support, please use our dedicated community forum at GitHub Discussions. PLEASE NOTE: If you choose to open an issue for your question instead, your issue may be closed and redirected to the forum.

Reporting issues

If you have found what you think is a bug, please file an issue. PLEASE NOTE: Issues that are identified as implementation questions or non-issues may be closed and redirected to GitHub Discussions.

Suggesting new features

If you are here to suggest a feature, first create an issue if it does not already exist. From there, we can discuss use cases for the feature and how it could be implemented.

Development

If you have been assigned to fix an issue or develop a new feature, please follow these steps to get started:

  • Fork this repository.

  • Use the Node.js version mentioned in .nvmrc.

    nvm use

  • Enable Corepack so the pnpm version mentioned in package.json is used.

    corepack enable

  • Install dependencies.

    pnpm install

  • Build all packages.

    pnpm build

  • Run tests.

    pnpm test

  • Run linting.

    pnpm lint

    pnpm lint:changed runs only the oracle/ rules, on the oracle files that your branch changes. It does not replace pnpm lint. If you work with a coding agent, the repository's hooks return oracle lint reports to it as it edits. Codex and Gemini CLI run project hooks only after you trust them in /hooks; review them again when they change. In a linked Git worktree, Codex reads project hooks from the main checkout, not from the worktree, so the hooks run there only after the main checkout has them.

  • Implement your changes and tests in the relevant package or example.

  • For a production change that adds, removes, or changes observable behavior, extend the primary oracle when it can express the governing law. A focused unit test can supplement the oracle but cannot replace it. Internal refactors need no new oracle coverage when existing oracles exercise the unchanged contract. For a change that is not a bug fix, a focused test alone is acceptable only when an oracle is not practical. Identify the relevant coverage-map entry and explain why you cannot extend its owner, create an independent oracle, or add a receiving witness. See the oracle coverage map and Oracle Testing Rubric.

  • For a bug fix, state how the pull request evaluated and closed the declared bug class. Include the violated law, exercised histories, production paths, observation checkpoints, RED/GREEN evidence, and remaining limits. A passing reproduction for one trace is not sufficient. The focused-test-only exception does not apply to bug fixes. Resolve known in-scope gaps before submitting.

  • Document your changes in the appropriate doc page.

  • Git stage your required changes and commit them.

  • Submit a PR for review.

Editing the docs locally and previewing changes

The documentation for all TanStack projects is hosted on tanstack.com, which is a TanStack Start application (https://github.com/TanStack/tanstack.com). You need to run this app locally to preview your changes in the TanStack/db docs.

Note

The website fetches doc pages from GitHub in production, and searches for them at ../db/docs in development. Your local clone of TanStack/db needs to be in the same directory as the local clone of TanStack/tanstack.com.

You can follow these steps to set up the docs for local development:

  1. Make a new directory called tanstack.
mkdir tanstack
  1. Enter that directory and clone the TanStack/db and TanStack/tanstack.com repos.
cd tanstack
git clone git@github.com:TanStack/db.git
# We probably don't need all the branches and commit history
# from the `tanstack.com` repo, so let's just create a shallow
# clone of the latest version of the `main` branch.
# Read more about shallow clones here:
# https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/#user-content-shallow-clones
git clone git@github.com:TanStack/tanstack.com.git --depth=1 --single-branch --branch=main

Note

Your tanstack directory should look like this:

tanstack/
   |
   +-- db/ (<-- this directory cannot be called anything else!)
   |
   +-- tanstack.com/
  1. Enter the tanstack/tanstack.com directory, install the dependencies, and run the app in dev mode.
cd tanstack.com
pnpm i
# The app will run on http://localhost:3000 by default
pnpm dev
  1. Visit http://localhost:3000/db/latest/docs/overview in the browser and see the changes you make in tanstack/db/docs there.

Warning

You will need to update docs/config.json if you add a new documentation page.

Running examples

  • Make sure you've installed dependencies in the repo's root directory.

    pnpm install

  • If you want to run an example against your local changes, run the relevant package build/watch command from the repo root if needed. Otherwise, examples may run against the latest published TanStack DB release.

  • Run the example from the selected example directory.

    pnpm dev

Note on standalone execution

If you want to run an example without installing dependencies for the whole repo, follow the instructions from the example's README.md file. It will then run against the latest TanStack DB release.

Changesets

This repo uses Changesets to automate releases. If your PR should release a new package version (patch, minor, or major), please run pnpm changeset and commit the generated file. If your PR affects docs, examples, styles, etc., you probably don't need to generate a changeset.

During the 1.0 release candidate period, use the same Changeset types. For a package at 1.0.0-rc.1, a patch produces 1.0.0-rc.1.1, and another patch produces 1.0.0-rc.1.2. A minor or major change advances the candidate number: 1.0.0-rc.1.2 becomes 1.0.0-rc.2. Packages already on stable 1.x versions, including @tanstack/query-db-collection and @tanstack/offline-transactions, continue to use normal semantic versioning and publish under npm's latest tag. Release candidates also publish under latest, per the maintainer's 2026-10-29 decision. Existing versions are not republished to move a tag: use npm dist-tag add <package>@<version> latest. This preserves any existing rc alias.

Pull requests

Maintainers merge pull requests by squashing all commits and editing the commit message if necessary using the GitHub user interface.

Use an appropriate commit type. Be especially careful with breaking changes.

Releases

For each new commit added to main, a GitHub Workflow is triggered which runs the Changesets Action. This generates a preview PR showing the impact of all changesets. When this PR is merged, the package will be published to npm.

The first 1.0 candidate Changeset enters Changesets prerelease mode through pnpm run changeset:version. Leave .changeset/pre.json in prerelease mode for subsequent candidate releases; the normal release workflow handles each patch or minor Changeset. When the candidates are ready for stable 1.0, run pnpm changeset pre exit and commit the resulting .changeset/pre.json change. The next Version Packages PR promotes the candidate packages to 1.0.0. Already stable packages keep their versions unless a pending Changeset explicitly releases them. Merge that PR to publish 1.0.