ESLint: Catch React Native Bugs Before Runtime

WHY IT EXISTS: React Native apps compile to native code, so a simple typo in a style prop or an undefined import might not surface until the app crashes on a specific device or OS version. Manual code review cannot reliably catch every unused variable, missing dependency, or accessibility violation across thousands of files. Static analysis was created to automate this inspection so errors are found before the bundler even starts.

THE MENTAL MODEL: Think of ESLint as a very picky pair programmer who reads every line you write the instant you save. It does not run your app; it parses the abstract syntax tree of your JavaScript or TypeScript and checks that tree against a set of agreed-upon rules. If the shape of the code violates a rule, it surfaces a message immediately.

HOW IT WORKS: ESLint takes a source file, converts it into an AST via a parser like @babel/eslint-parser or @typescript-eslint/parser, then traverses that tree with rules. Each rule is a function that listens for specific node types, such as JSXOpeningElement or ImportDeclaration. In React Native, plugins like eslint-plugin-react-hooks and eslint-plugin-react-native add rules for Hook call order, unused style references, or platform-specific color contrasts. The tool outputs errors or warnings based on severity levels configured in your .eslintrc file.

WHEN TO USE IT: Use ESLint in three places: inside your IDE on every save for immediate feedback, in a pre-commit hook to block bad code from entering version control, and in CI to reject pull requests that introduce new violations. It is especially valuable when multiple engineers touch the same codebase, because it enforces style and safety constraints automatically rather than through human nagging.

WHEN NOT TO USE IT: Do not rely on ESLint to catch logic errors, race conditions, or performance bottlenecks. It knows nothing about runtime state, network latency, or actual user interactions. It also cannot validate that your native modules are correctly linked or that your API responses match expected schemas.

ONE CANONICAL EXAMPLE: A common React Native bug is forgetting to include the accessibilityLabel prop on a TouchableOpacity. Without it, screen readers announce the component as unlabeled, making the app unusable for visually impaired users. The rule jsx-a11y/accessible-emoji or react-native-a11y/has-accessibility-props flags this at write time. The engineer sees a squiggle in the editor, adds the prop, and the potential production bug never reaches the simulator, let alone a user device.