Contributing to React Compiler
Thank you for your interest in contributing to React Compiler! This guide will help you set up your development environment and understand the contribution workflow.Getting Started
Prerequisites
- Node.js: Version 18 or higher
- Yarn: Package manager (v1 or v3+)
- Git: For version control
- Editor: VS Code recommended (with TypeScript support)
Clone the Repository
Install Dependencies
Build the Compiler
Development Workflow
Running Tests
React Compiler uses a custom test runner calledsnap:
Test Fixtures
Test fixtures are located in:feature-name.js- Normal test casefeature-name.expect.md- Expected outputerror.todo-*.js- Known limitation (graceful bailout)error.bug-*.js- Known bug
Adding a New Test
- Create fixture file:
- Write test code:
my-feature.js
- Generate expected output:
- Verify output:
Compiling Arbitrary Files
Test the compiler on any file:Minimizing Test Cases
Reduce a failing test to minimal reproduction:Code Structure
Key Directories
Important Files
src/Entrypoint/Pipeline.ts- Main compilation pipelinesrc/HIR/HIR.ts- HIR type definitionssrc/HIR/Environment.ts- Configuration schemasrc/CompilerError.ts- Error handling
Making Changes
Modifying a Pass
Before modifying a pass, read its documentation:- Purpose and invariants
- Input/output guarantees
- Algorithm description
- Edge cases
- Find the pass:
- Read the documentation:
- Locate the implementation:
- Make your changes
- Add test cases
- Run tests:
Adding a New Pass
- Create the pass file:
src/MyCategory/MyNewPass.ts
- Add to pipeline:
src/Entrypoint/Pipeline.ts
- Add documentation:
- Write tests:
Adding Configuration Options
- Update schema:
src/HIR/Environment.ts
- Use in code:
- Document in configuration.mdx
Error Handling
Error Types
When to Use Each
throwTodo: Known limitation, expected pattern that’s not yet supportedinvariant: Unexpected state indicating a compiler bugInvalidReact: User code violates React’s rulesInvalidJS: Syntactically invalid JavaScript
Debugging
Debug Output
Run tests with debug logging:Custom Logger
Create a debug logger:Breakpoints
Set breakpoints in VS Code:- Open file in editor
- Click left of line number to add breakpoint
- Run test in debug mode:
F5
Print HIR
Use pretty printer:Submitting Changes
Commit Guidelines
React Compiler uses Sapling (similar to Mercurial):Commit Message Format
Opening a Pull Request
- Push your changes:
- Create PR on GitHub:
- Base:
facebook/react:main - Title: Brief description
- Description: Detailed explanation + test plan
- Address review feedback
- Wait for CI to pass
PR Checklist
- Tests added for new functionality
- All tests passing (
yarn snap) - Pass documentation updated (if modifying pass)
- Configuration documented (if adding options)
- Examples added to fixtures
- Commit message follows format
- No unrelated changes
Code Style
TypeScript
- Use explicit types for public APIs
- Prefer
interfaceovertypefor objects - Use
constoverletwhen possible - Avoid
any- useunknowninstead
Naming Conventions
- Files: PascalCase for classes, camelCase for utilities
- Variables: camelCase
- Types: PascalCase
- Constants: UPPER_SNAKE_CASE
- Private fields:
#privateField(private class fields)
Formatting
Code is automatically formatted. Run:Getting Help
Resources
- Documentation: Read
docs/anddocs/passes/ - CLAUDE.md: Compiler knowledge base
- GitHub Issues: Search existing issues
- Discord: React Compiler channel
Asking Questions
When asking for help, provide:- What you’re trying to do
- What you’ve tried
- Minimal reproduction (test fixture)
- Expected vs actual behavior
- Error messages (full output)
Common Tasks
Update Expected Output
Run Specific Category
Check Type Errors
Run Linter
Build for Production
Advanced Topics
Custom Test Runner
Thesnap runner is in packages/snap/. It:
- Discovers fixtures
- Compiles code
- Generates expected output
- Executes code in both versions
- Compares results
Compiler Profiling
Enable timing:Memory Profiling
Use Node inspector:Best Practices
Writing Tests
- One concept per fixture - Each test should validate one behavior
- Descriptive names - Name clearly indicates what’s tested
- Comments - Explain why behavior is expected
- Edge cases - Test boundary conditions
Code Quality
- Keep passes focused - Each pass should do one thing well
- Document invariants - State assumptions clearly
- Error messages - Make them actionable
- Performance - Avoid O(n²) algorithms when possible
Review Process
- Self-review - Review your own changes first
- Test thoroughly - Run on real-world code
- Explain changes - Help reviewers understand
- Respond promptly - Address feedback quickly
Next Steps
Architecture
Understand the compiler pipeline
HIR
Learn the intermediate representation
Optimization Passes
Study specific passes
Configuration
Configuration options reference