Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
158 lines (106 loc) · 5.44 KB

CONTRIBUTING.md

File metadata and controls

158 lines (106 loc) · 5.44 KB

Contributing to Rock

Development Process

All work on Rock happens directly on GitHub. Contributors send pull requests which go through review process.

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 main (a guide on how to fork a repository).
  2. Run pnpm i to install all required dependencies.
  3. Run pnpm watch to automatically build the changed files.
  4. Now you are ready to do the changes.

Testing your changes

Please make sure the version of React Native matches the one present in devDependencies of Rock. Otherwise, you may get unexpected errors.

Setup

Because of a modular design of the Rock, we recommend developing using symbolic links to its packages. This way you can use it seamlessly in the tested project, as you'd use the locally installed Rock CLI. Here's what you need to run in the terminal:

cd /path/to/cloned/rock/
pnpm link-packages

And then in your test project link dependencies you're using, e.g.:

cd /my/test/project/
pnpm link rock @rock-js/platform-android @rock-js/platform-ios @rock-js/plugin-metro

Hoist pnpm dependencies

Set node-linker to hoisted in your test project's .npmrc file for pnpm to place the node_modules in a way that React Native platform tooling expects:

node-linker=hoisted

Update Metro configuration

When using Metro plugin, you'll need to update the watchFolders to hint Metro to look for symlinks in Rock project. You can do this by adding the following to your metro.config.js:

{
  watchFolders: [path.resolve(__dirname, '../path/to/rock')],
}

This configuration is not necessary when using Re.Pack plugin.

Run in your test project

pnpm rock start
pnpm rock run:android

Testing Create Rock App project

In order to test changes to create-app package, you need to run the following commands:

# Ensure fresh build
pnpm build

# Start local verdaccio registry (in one terminal), keep it open
pnpm verdaccio:init

# Publish packages to verdaccio (in another terminal)
pnpm verdaccio:publish

# Remove pnpm dlx cache, so that new version of package is used
rm -rf ~/Library/Caches/pnpm/dlx/

# Run tests
pnpm e2e

# Or Create Rock app
NPM_CONFIG_REGISTRY=http://localhost:4873 pnpm create rock --registry http://localhost:4873
# Then use pnpm install with registry
echo "node-linker=hoisted" > .npmrc
NPM_CONFIG_REGISTRY=http://localhost:4873 pnpm install
# Then link packages (see above)
pnpm link --global ...

# Clean up
pnpm verdaccio:reset

Typechecking, linting and testing

Currently we use TypeScript for typechecking, eslint with prettier for linting and formatting the code and jest for testing.

  • pnpm lint: run eslint and prettier
  • pnpm test: run unit tests

Commit message convention

We prefix our commit messages with one of the following to signify the kind of change:

  • build: Changes that affect the build system or external dependencies
  • ci, chore: Changes to our CI configuration files and scripts
  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code
  • test: Adding missing tests or correcting existing tests

Sending a pull request

When you're sending a pull request:

  • Prefer small pull requests focused on one change.
  • Verify that TypeScript, eslint and all tests are passing.
  • Preview the documentation to make sure it looks good.
  • Follow the pull request template when opening a pull request.

Publishing workflow

This part is for maintainers only, documenting steps to manually publish the packages with Changesets.

Stable version

  1. Pull latest changes for the stable branch.
  2. Run pnpm run publish, it will tag the packages as latest.
  3. Chose an appropriate version from the available options.
  4. Create release notes in the project's Release tab.

Prerelease

  1. Pull latest changes for the main branch.
  2. Run pnpm run publish:next, it will tag the packages as next.
  3. Use Custom prerelease option and go with -alpha.N convention.
  4. Create release notes in the project's Release tab.

Legacy version

  1. Pull latest changes for the N.x branch (where N stands for major legacy version).
  2. Run pnpm run publish --dist-tag N.x to tag the packages as N.x.
  3. Chose an appropriate version from the available options.
  4. Create release notes in the project's Release tab.

Reporting issues

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

Stale Bot

This repository is using bot to automatically mark issues and PRs as stale and close them. The "stale" label is added after 90 days of inactivity, and it's getting closed 7 days later. If you find the issue important or you want to keep it open for any particular reason, please show any activity in the issue or contact maintainers to add the "no-stale-bot" label, which prevents bot from closing the issues.

License

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