Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/aravind3566/react-native-in-app-updates/llms.txt

Use this file to discover all available pages before exploring further.

Contributions to react-native-in-app-updates are welcome regardless of size. This guide walks you through the full development workflow — from forking the repository to submitting a polished pull request — so you can contribute with confidence.

​
Project Structure

The repository is a monorepo managed with Yarn workspaces (Yarn 3.6.1). It contains two packages:
PackageLocationPurpose
Library/ (root)The published react-native-in-app-updates npm package
Example appexample/A React Native app that exercises the library locally
The example app is wired to consume the local version of the library directly, so any JavaScript changes you make are reflected immediately without a rebuild. Native code changes (Kotlin, Swift, Objective-C) require a full rebuild of the example app.
This project uses Yarn workspaces — you cannot use npm for development. Running npm install will produce incorrect dependency resolution and break the workspace linking.

​
Getting Started

1

Fork and clone the repository

Fork the repo on GitHub, then clone your fork locally:
git clone https://github.com/<your-username>/react-native-in-app-updates.git
cd react-native-in-app-updates
2

Install all workspace dependencies

Run yarn from the root of the repository. This installs dependencies for both the library package and the example/ app in one step:
yarn
3

Run the example app

Start the Metro bundler, then launch the example app on your target platform:
yarn example start
To edit Android native code, open example/android in Android Studio and locate the source files under react-native-in-app-updates → Android.To edit iOS native code, open example/ios/InAppUpdatesExample.xcworkspace in Xcode and find the files under Pods > Development Pods > react-native-in-app-updates.
4

Make your changes

Edit source files in src/ for JavaScript/TypeScript changes, or in android/ / ios/ for native changes.
Native code changes require a full rebuild of the example app. Stop Metro, then re-run yarn example android or yarn example ios to pick up your changes.
5

Run linting and type checking

Verify that your changes pass TypeScript type checking and ESLint before committing:
yarn typecheck
yarn lint
To automatically fix formatting issues detected by Prettier:
yarn lint --fix
6

Run the test suite

Add tests for your change where possible, then run the full Jest suite:
yarn test
Pre-commit hooks will re-run the linter and tests automatically when you commit, so passing them locally avoids surprises.
7

Commit using conventional commits

Write your commit message following the Conventional Commits specification (see below). Pre-commit hooks validate the format automatically via commitlint.
git commit -m "fix: resolve unresolved reference in InAppUpdatesModule"
8

Open a pull request

Push your branch and open a PR against the main branch. Follow the pull request template and keep PRs focused on a single change. For proposals that affect the public API or implementation architecture, open an issue first to discuss with maintainers before writing code.

​
Available Scripts

All commands are run from the root of the repository: 
# Install all workspace dependencies
yarn

# Type-check the library with TypeScript
yarn typecheck

# Lint all JS/TS/TSX files with ESLint
yarn lint

# Auto-fix formatting errors with Prettier
yarn lint --fix

# Run unit tests with Jest
yarn test

# Start the Metro bundler for the example app
yarn example start

# Run the example app on Android
yarn example android

# Run the example app on iOS
yarn example ios

# Publish a new version to npm via release-it
yarn release

​
Commit Message Convention

This project follows the Conventional Commits specification. Commit messages are validated by commitlint on every commit. The format is: 
<type>: <short description>
TypeWhen to useExample
fixBug fixesfix: resolve crash due to deprecated method
featNew featuresfeat: add flexible update flow support
refactorCode restructuring with no behaviour changerefactor: migrate class component to hooks
docsDocumentation changes onlydocs: add usage example for immediate update
testAdding or updating teststest: add integration tests for update status
choreTooling or configuration changeschore: update CI config to Node 20
Conventional commit types also drive automated changelog generation via @release-it/conventional-changelog when maintainers publish a new release.

​
Linting and Testing Requirements

The project uses the following toolchain to enforce code quality:
  • TypeScript — static type checking across the library source
  • ESLint + Prettier — linting and consistent code formatting
  • Jest — unit testing
All three checks must pass before a pull request can be merged. Pre-commit hooks run the linter and tests automatically, but it is good practice to run them manually before pushing.

​
Sending a Pull Request

Keep PRs focused

Prefer small, single-purpose pull requests. Large, multi-concern PRs are harder to review and slower to merge.

Discuss API changes first

For changes to the public API or core implementation, open an issue to align with maintainers before investing time in code.

Verify all checks pass

Confirm that yarn typecheck, yarn lint, and yarn test all pass locally before opening your PR.

New to open source?

The free egghead series How to Contribute to an Open Source Project on GitHub is a great starting point.

Build docs developers (and LLMs) love

Get started for freeTalk to us