Thank you for your interest in contributing to b10cks Open Source SDKs! We welcome contributions from the community to help improve our SDKs and make them more useful for everyone.
- Fork the Repository: Start by forking the repository to your own GitHub account.
- Create a Branch: Create a new branch for your feature or bug fix.
- Make Changes: Make your changes in the new branch. Ensure that your code adheres to the project's coding standards and guidelines.
- Write Tests: If applicable, write tests for your changes to ensure they work as expected.
- Commit Your Changes: Commit your changes with a clear and concise commit message that describes what you have done. We're using gitmoji-style commit messages, so please follow that format.
- Create a Pull Request: Go to the original repository and create a pull request (PR) from your branch. Provide a clear description of the changes you made and why they are necessary.
- Review and Address Feedback: Be open to feedback from the maintainers. You may need to make additional changes based on their suggestions.
- Ensure you have Node.js installed (version 24.7 or higher).
- Install pnpm as the package manager. The exact version is pinned via the
packageManagerfield, so pnpm installs it for you.
- Clone the repository:
git clone https://github.com/b10cks/sdk.git
- Inside the project directory, run to install the required dependencies:
pnpm install
Every pull request runs .github/workflows/ci.yml:
| Job | What it does |
|---|---|
| Lint & format | oxlint --deny-warnings and oxfmt --check |
| Build & test | pnpm build, pnpm typecheck, pnpm test on Node 24 and 26 |
| Changeset present | Fails if you changed a package without adding a changeset |
Run the same checks locally with pnpm lint, pnpm format, pnpm build, pnpm typecheck and
pnpm test.
Releases are driven by changesets and
.github/workflows/release.yml. Nothing is versioned or published
from a developer machine.
- Add a changeset to your PR describing the user-facing change:
Pick the affected packages and the bump type (patch/minor/major), then commit the generated file in
pnpm changeset
.changeset/. Changes that need no release (docs, CI, tests) can skip this by adding theskip-changesetlabel to the PR. - Merge the PR into
main. The release workflow collects all pending changesets and opens (or updates) a🔖 Version packagespull request that applies the version bumps and changelog entries. - Merge the version PR when you want to ship. The workflow then runs
pnpm release(build +changeset publish), pushes the git tags and creates a GitHub release per package.
- Settings → Actions → General → Workflow permissions: enable Allow GitHub Actions to create and approve pull requests, otherwise the version PR cannot be opened.
- npm trusted publishing: for each published package, add a trusted publisher on npmjs.com
(Settings → Trusted publishers) pointing at repository
b10cks/sdkand workflow.github/workflows/release.yml. This replaces long-lived npm tokens and gives the published tarballs provenance attestations. Packages:@b10cks/client,@b10cks/mgmt-client,@b10cks/mcp-server,@b10cks/cli,@b10cks/richtext,@b10cks/vue,@b10cks/react,@b10cks/svelte,@b10cks/nuxt,@b10cks/next. - Trusted publishing requires pnpm 11 or newer, which is why the
packageManagerfield is pinned to a pnpm 11 release. If a package has no trusted publisher configured yet, anNPM_TOKENsecret is used as a fallback.
If you have any questions or need support, feel free to reach out to the maintainers. We are here to help!
- You can check the b10cks documentation.
- Open an issue in this repository if you encounter any problems or have questions about the SDKs.
- Join our Discord community for community support.