[expo-router] Generated typed routes should be committed to version control #41872

Summary

The current recommendation to gitignore generated typed routes (.expo/types/router.d.ts) creates significant developer experience issues in team environments. This issue proposes reconsidering the recommendation to allow (or encourage) committing these files.

Current Behavior

Per the typed routes documentation:

By default, these generated types are configured to be untracked by Git and will be added to the local .gitignore file.

Generated typed routes are automatically excluded from version control.

Problem

This creates several workflow issues for development teams:

1. Branch Switching Breaks TypeScript

# Developer A creates new route in feature branch
git checkout feature/new-route
# Types exist locally, everything works

# Developer B switches to that branch
git checkout feature/new-route
yarn typecheck  # ❌ FAILS - types don't exist yet
# IDE shows type errors everywhere
# Can't run CI checks until manually starting dev server

2. Post-Pull Type Errors

When pulling latest changes from main that include new routes:

• IDE immediately shows type errors for the new routes
• TypeScript compiler fails
• Developer must run expo start briefly just to regenerate types
• This breaks automated workflows (pre-commit hooks, IDE type checking, etc.)

3. CI/CD Complexity

While npx expo customize tsconfig.json is mentioned for CI (#34686), this:

• Adds complexity to CI setup
• Requires starting/stopping the dev server in CI just for type generation
• Increases CI build times
• Doesn't help with local development

4. Inconsistent Developer Experience

• Routes are defined in the filesystem (committed)
• Types are generated from the filesystem (not committed)
• Mismatched state between routes and their types is common

Proposed Solution

Allow (or recommend) committing generated typed routes by:

1. Removing .expo/ from default gitignore (or making it configurable)
2. Updating documentation to show committing types as a valid approach

Why This Makes Sense

1. Deterministic Output: The generated router.d.ts is deterministic - same routes always produce the same types
2. Low Change Frequency: Routes don't change as often as code
3. Minimal Merge Conflicts: The file is typically one long line, rarely conflicts
4. Common Pattern: Other frameworks (Next.js, SvelteKit) commit generated types
5. Better DX: Types are immediately available after git checkout or git pull

Similar Patterns in Other Frameworks

• Next.js: Recommends committing .next/types/ directory for App Router types
• Prisma: Generated client is committed or published as package
• GraphQL Codegen: Generated types are typically committed

Environment

• Expo SDK: 54
• expo-router: ~6.0.19
• Environment: Monorepo with multiple developers

Related Issues

• #34686 - Documentation about CI type generation
• #30209 - Typed routes generation issues
• #23404 - Concerns about brittleness of CLI-dependent typing

Thank you for considering this!