Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
119 lines (77 loc) · 5.37 KB

CONTRIBUTING.md

File metadata and controls

119 lines (77 loc) · 5.37 KB
Raw

Contributing to Re.Pack

Code of Conduct

We want this community to be friendly and respectful to each other. Please read the full text so that you can understand what actions will and will not be tolerated.

Requirements

  • Node 20+ (although Node 18 is still supported but has now reached EOL)
  • pnpm 8 (use it via corepack install)

Our Development Process

All development is done directly on GitHub, and all work is public.

Development workflow

Working on your first pull request? You can learn how from this free series: How to Contribute to an Open Source Project on GitHub.

  1. Fork the repo and create your branch from default branch (usually main) (a guide on how to fork a repository).
  2. Run pnpm install to install & set up the development environment.
  3. Do the changes you want and test them out in the TesterApp (apps/tester-app) before sending a pull request.

Commit message convention

We follow the conventional commits specification for our commit messages:

  • fix: bug fixes, e.g. fix Button color on DarkTheme.
  • feat: new features, e.g. add Snackbar component.
  • refactor: code refactor, e.g. new folder structure for components.
  • docs: changes into documentation, e.g. add usage example for Button.
  • test: adding or updating tests, e.g. unit, snapshot testing.
  • chore: tooling changes, e.g. change circleci config.
  • BREAKING CHANGE: for changes that break existing usage, e.g. change API of a component.

Changesets

When adding new features, fixes or doing any changes to public API, behavior or logic is required to create a changeset explaining what has been modified.

Once code changes are done, run pnpm changeset add and follow the CLI instructions to write a changeset.

You can learn more about changesets here: https://github.com/changesets/changesets

Linting and tests

We use typescript for type checking and biome for linting and formatting the code, and jest/vitest for testing. You should run the following commands before sending a pull request:

  • pnpm typecheck: type-check files with tsc.
  • pnpm lint: lint files with biome.
  • pnpm test: run unit tests with jest/vitest.

Sending a pull request

  • Prefer small pull requests focused on one change.
  • Verify that typescript, biome and all tests are passing.
  • Verify all in-code documentation is correct (it will be used to generate API documentation).
  • Write changeset if necessary.
  • Follow the pull request template when opening a pull request.

Running the example

The example TesterApp uses React Native Community CLI so make sure you have your environment setup to build native apps.

You can then use Xcode/Android Studio/Gradle to build application or run pnpm react-native webpack-start and pnpm react-native run-ios/pnpm react-native run-android to start development server and run applications in development mode.

Working on documentation

The documentation is a part of the website, which is stored in website directory and uses rspress - an SSG framework that leverages rspack. To start working on the docs, either run pnpm website:start from the root of the repository, or pnpm start from inside of the website directory.

Publishing a release

We use changesets and the Changesets GitHub Action to bump package versions, update package CHANGELOG.md files, publish to npm, and create GitHub releases.

Stable releases

When releasable changesets are merged to main, the Release workflow creates or updates a chore: changeset version pull request. This PR contains the exact package version changes and generated changelog entries for the next release.

Review the version numbers and changelog entries in that PR before merging it. When the version PR is merged to main, the same workflow runs pnpm release, publishes the packages to npm, pushes the release tags, and creates GitHub releases from the generated changelog entries.

Canary releases

Canary releases are published manually from the Release workflow in GitHub Actions. Run it only from the main branch. The workflow creates snapshot versions with the canary snapshot label, runs the full release checks, and publishes with the canary npm dist-tag without committing version changes or creating GitHub releases.

npm trusted publishing

Releases use npm trusted publishing instead of long-lived npm automation tokens. Do not add NPM_TOKEN or NODE_AUTH_TOKEN secrets for publishing.

Each published package in the @callstack scope must have trusted publishing configured on npmjs.com with GitHub Actions as the publisher:

  • Owner: callstack
  • Repository: repack
  • Workflow file: release.yml
  • Allowed action: npm publish

The release workflows intentionally disable package-manager caching to avoid using a pnpm cache during publishing.

Reporting issues

You can report issues on our bug tracker. Please follow the issue template when opening an issue.

License

By contributing to Re.Pack, you agree that your contributions will be licensed under its MIT license.