How to Contribute

Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.

Our Development Process

Most changes from engineers at Facebook will sync to GitHub through a bridge with Facebook's internal source control. Changes from the community are handled through GitHub pull requests. Once a change made on GitHub is approved, it will first be imported into Facebook's internal source control. The change will eventually sync back to GitHub as a single commit once it has passed Facebook's internal tests.

Branch Organization

We will do our best to keep the master branch in good shape, with tests passing at all times. Sometimes, commits from Facebook engineers may land on master, temporarily breaking tests. While we have a comprehensive suite of tests that every diff must go through before it syncs out to GitHub, there are still some differences in development environments that prevent us from catching every one of these failures. We will do our best to resolve these quickly.

Each React Native version is built from a release branch named after the version (e.g. 0.NN-stable). Each release branch is cut from the master branch and subjected to a 30 day soak period, during which contributors will closely monitor for any regressions. You can opt into these release candidates by installing react-native@next from npm. The release will eventually be promoted to stable, and published to npm as react-native@latest.

To see what changes are coming and provide better feedback to React Native contributors, use the latest release candidate whenever possible. By the time a release candidate is released, the changes it contains will have been shipped in production Facebook apps for over two weeks.

Get Involved

There are many ways to contribute to React Native, and many of them do not involve writing any code. Here's a few ideas to get started:

Simply start using React Native. Go through the Getting Started guide. Does everything work as expected? If not, we're always looking for improvements.

Look through the open issues. Provide workarounds, ask for clarification, or suggest labels. Active community members can get access to our issue management tools, unlocking the ability to label, close, or re-open issues.

If you find an issue you would like to fix, open a pull request. Issues tagged as Good first issue are a good place to get started.

Read through the docs. If you find anything that is confusing or can be improved, you can make edits by clicking "Edit" at the top of most docs.

Browse Stack Overflow and answer questions. This will help you get familiarized with common pitfalls or misunderstandings, which can be useful when contributing updates to the documentation.

Before opening your pull request, make sure you have fully tested your changes. Test your changes locally and by running the various tests provided.

Check out the Testing your changes guide to find out about the numerous tests which has been provided to help ensure that any new changes wont cause a regression.

Pull requests

Your first pull request

So you have decided to contribute code back to upstream by opening a pull request. You've invested a good chunk of time, and we appreciate it. We will do our best to work with you and get the PR looked at.

Proposing a change

If you intend to change the API, or make any non-trivial changes to the implementation, we recommend filing an issue. This lets us reach an agreement on your proposal before you put significant effort into it.

If you're only fixing a bug, it's fine to submit a pull request right away but we still recommend to file an issue detailing what you're fixing. This is helpful in case we don't accept that specific fix but want to keep track of the issue.

Sending a pull request

Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.

Please make sure the following is done when submitting a pull request:

Coding Style

We use Prettier to format our JavaScript code. This saves you time and energy as you can let Prettier fix up any formatting issues automatically through its editor integrations, or by manually running npm run prettier. We also use a linter to catch styling issues that may exist in your code. You can check the status of your code styling by simply running npm run lint.

However, there are still some styles that the linter cannot pick up, notably in Java or Objective-C code.

Objective-C:

Space after @property declarations

Brackets on everyif, on the same line

- method, @interface, and @implementation brackets on the following line

Try to keep it around 80 characters line length (sometimes it's just not possible...)

* operator goes with the variable name (e.g. NSObject *variableName;)

Java:

If a method call spans multiple lines closing bracket is on the same line as the last argument.

If a method header doesn't fit on one line each argument goes on a separate line.

100 character line length

License

By contributing to React Native, you agree that your contributions will be licensed under the LICENSE file.