How does Atlas ensure it finds all deprecated API calls in an Expo app?

Atlas employs a hybrid approach, first using its `lsp` tool to leverage the language server's `findReferences` for explicit calls. It then cross-checks this with a project-wide `grep` search to catch dynamic, string-based, or configuration-related usages, ensuring comprehensive coverage across your Expo codebase, including `app.json` or `app.config.ts`.

Can Atlas handle complex file structures like `expo-router` routes?

Yes, Atlas is designed to operate within Expo projects, understanding common structures like `expo-router` file routes. Its `lsp` tool can work through these routes to find references, and `grep` can search across any file, ensuring that even changes within route definitions or related components are identified and migrated correctly.

What happens if a patch fails to apply during an Expo migration?

Atlas's `apply_patch` tool is designed for safety. If the expected context or old lines for a patch are not found in an Expo file, `apply_patch` will explicitly fail with a 'Failed to find expected lines' error. It will not attempt to guess or misapply the patch, preventing unintended changes and allowing you to inspect the file's drift.

How does Atlas verify changes in an Expo project?

After each file modification, Atlas uses its `bash` tool to execute `npx jest-expo` for the affected tests. The corresponding `todowrite` entry is only marked as complete once `jest-expo` reports all tests passing. This immediate, per-file verification loop ensures that each migration step maintains the stability of your Expo application.

Does Atlas integrate with Expo's package manager?

Yes, Atlas is configured to install packages using `npx expo install`, ensuring that package versions remain pinned to your SDK release. This integration maintains consistency with Expo's recommended practices for dependency management within your project.

How does Atlas handle code formatting after a migration?

Atlas can be configured to run `prettier` on the diffs it generates. This ensures that any code changes made during the migration, whether in `app/` components or config plugins, adhere to your project's established formatting standards, maintaining code consistency in your Expo codebase.

Can Atlas help with config plugins for native capabilities in Expo?

Yes, Atlas can be asked to add native capabilities through a config plugin rather than requiring manual edits to `ios/` and `android/` directories. This ensures that your prebuild process remains reproducible and aligns with Expo's approach to managing native project configurations.

Migrate a deprecated API across every callsite in Expo with Atlas in 2026

Migrating a deprecated API across an entire Expo codebase without missing a single callsite is efficiently handled by Atlas, which leverages `lsp` for comprehensive enumeration, `apply_patch` for precise modifications, and `bash` to integrate with `jest-expo` for immediate test verification, ensuring a complete and safe transition.

How Atlas enumerates all deprecated API calls in Expo

Atlas ensures no deprecated API callsite is missed in your Expo project by combining `lsp` and `grep` for a robust, two-phase enumeration process. This approach guarantees 100% coverage, even for dynamic or string-based usages that might elude a language server alone.

To begin a migration in an Expo project, Atlas first uses its `lsp` tool to invoke the `findReferences` operation on the deprecated symbol. This leverages the language server's deep understanding of your codebase, including `expo-router` file routes and `app.json` or `app.config.ts` configurations, to identify all direct references. For instance, if you're deprecating a function within a utility module, `lsp` will pinpoint every explicit import and call. Atlas then cross-checks this initial list with its `grep` tool, performing a keyword search across your entire project. This `grep` step is crucial for catching any dynamic invocations, string literals that reference the deprecated API, or usages within configuration files like `eas.json` that might not be directly linked by the language server. This hybrid semantic and keyword retrieval, fused by reciprocal rank fusion, ensures a complete and accurate list of all callsites, providing a solid foundation for the migration workflow.

Tracking migration progress with todowrite in Expo projects

Atlas transforms the enumerated callsites into actionable `todowrite` entries, providing a clear, visible roadmap for your Expo API migration. This ensures that every single one of the identified 0-999+ callsites is explicitly tracked, preventing any partial progress from being silently overlooked.

Once Atlas has enumerated all callsites of the deprecated API within your Expo project, it creates a distinct `todowrite` entry for each one. This is a critical step for managing the migration of a large codebase, as it makes partial progress visible and ensures that no callsite is silently skipped. Each `todowrite` entry represents a specific task: migrating a single instance of the deprecated API. As Atlas processes each callsite, it updates the status of its corresponding `todowrite` entry. This granular tracking is particularly valuable in Expo projects, where changes might span across various files, from `app/` directory components to custom config plugins. The `todowrite` system provides a transparent overview of the migration's status, allowing you to see exactly how many callsites remain and which ones have been successfully updated and verified.

Applying changes and running tests in Expo with Atlas

Atlas migrates each deprecated API callsite in your Expo project using `apply_patch` for precise, context-anchored edits, followed by `bash` to execute `jest-expo` tests. This ensures that every change is validated immediately, preventing regressions and maintaining the stability of your application's 2026 codebase.

For each `todowrite` entry, Atlas uses its `apply_patch` tool to perform the actual migration. This tool is designed for precision: it seeks the hunk's context and old_lines, and will explicitly throw a 'Failed to find expected lines' error rather than misapplying a patch to a drifted file. This robust mechanism prevents unintended changes in your Expo project, whether you're modifying a component in `app/` or a utility function. After `apply_patch` successfully modifies a file, Atlas immediately runs the affected tests using its `bash` tool. For Expo projects, this means executing `npx jest-expo` to run your unit and integration tests. Atlas is configured to respect your project's testing setup, ensuring that the correct test suite is invoked. Only once `jest-expo` reports all tests passing for the modified file is the corresponding `todowrite` entry marked as completed. This rigorous, per-file testing loop, which Atlas can fan out to subagents for parallel execution, guarantees that each migration step is safe and verified, preventing the introduction of new bugs.

Ensuring a complete migration and cleanup in Expo

Atlas concludes the deprecated API migration in your Expo project by performing a final `grep` scan to confirm zero remaining hits, followed by the deletion of the old implementation. This meticulous 2-step cleanup ensures that your codebase is fully transitioned and free of any lingering deprecated code.

After all `todowrite` entries have been completed and verified, Atlas performs a final, comprehensive check to ensure the deprecated API has been entirely removed from your Expo project. It uses its `grep` tool one last time to search for any remaining instances of the deprecated symbol across the entire codebase. This final `grep` pass acts as a safeguard, catching any edge cases or overlooked dynamic usages that might have slipped through. If `grep` returns zero hits, Atlas then proceeds to delete the old implementation of the deprecated function or module. This complete removal is crucial for maintaining a clean and modern codebase, especially in Expo projects where dependencies and SDK versions evolve. Atlas can also read git branches, status, and diffs, and can stage and create commits on your behalf, allowing for a clean, atomic commit of the entire migration, including the deletion of the old code, ensuring your `app.json` or `app.config.ts` based project is fully updated.

Atlas's safety and review mechanisms for Expo migrations

Atlas prioritizes safety and developer control during Expo API migrations, employing permission-gated tool calls, a read-only plan agent, and unified diffs for every edit. This multi-layered approach ensures that you, the developer, have 100% oversight and approval over every change made to your project.

Atlas is built with robust safety and review mechanisms, crucial for making large-scale changes in an Expo codebase. Every Atlas tool call, whether it's `lsp`, `grep`, `todowrite`, `apply_patch`, or `bash`, is permission-gated against allow, ask, and deny rules before it runs. This means you explicitly approve each action. Before making any modifications, Atlas drafts a comprehensive plan in a read-only plan agent and asks for your approval before switching to a build agent. This allows you to review the entire strategy for migrating the deprecated API, from enumeration to testing with `jest-expo`. Furthermore, Atlas computes a unified diff for every file edit and surfaces it for your approval before writing. This visual diff allows you to inspect every line change, ensuring that the modifications align with your expectations for your `app/` directory files or `eas.json` configurations. Atlas also snapshots file changes as git patches, so edits can be easily diffed and rolled back if needed, providing an additional layer of safety and control over your Expo project's evolution.

Step by step

01Initialize Atlas in your Expo project, ensuring it can read your `app.json` or `app.config.ts` and `app/` directory.
02Ask Atlas to enumerate all callsites of the deprecated symbol using the `lsp` tool's `findReferences` operation, cross-checking with `grep` for dynamic usages.
03Instruct Atlas to create one `todowrite` entry for each identified callsite, making all migration tasks visible.
04Approve Atlas to migrate each callsite using `apply_patch`, which will precisely seek and replace the deprecated code.
05After each file modification, Atlas will use `bash` to run `npx jest-expo` for affected tests; approve the `todowrite` entry only if tests pass.
06Once all `todowrite` entries are complete, ask Atlas to perform a final `grep` for the deprecated symbol to confirm zero remaining hits.
07Approve Atlas to delete the old implementation of the deprecated API, ensuring a clean codebase.
08Review the unified diffs for all changes and approve Atlas to stage and create a commit for the entire migration.

Frequently asked questions

How does Atlas ensure it finds all deprecated API calls in an Expo app?: Atlas employs a hybrid approach, first using its `lsp` tool to leverage the language server's `findReferences` for explicit calls. It then cross-checks this with a project-wide `grep` search to catch dynamic, string-based, or configuration-related usages, ensuring comprehensive coverage across your Expo codebase, including `app.json` or `app.config.ts`.
Can Atlas handle complex file structures like `expo-router` routes?: Yes, Atlas is designed to operate within Expo projects, understanding common structures like `expo-router` file routes. Its `lsp` tool can work through these routes to find references, and `grep` can search across any file, ensuring that even changes within route definitions or related components are identified and migrated correctly.
What happens if a patch fails to apply during an Expo migration?: Atlas's `apply_patch` tool is designed for safety. If the expected context or old lines for a patch are not found in an Expo file, `apply_patch` will explicitly fail with a 'Failed to find expected lines' error. It will not attempt to guess or misapply the patch, preventing unintended changes and allowing you to inspect the file's drift.
How does Atlas verify changes in an Expo project?: After each file modification, Atlas uses its `bash` tool to execute `npx jest-expo` for the affected tests. The corresponding `todowrite` entry is only marked as complete once `jest-expo` reports all tests passing. This immediate, per-file verification loop ensures that each migration step maintains the stability of your Expo application.
Does Atlas integrate with Expo's package manager?: Yes, Atlas is configured to install packages using `npx expo install`, ensuring that package versions remain pinned to your SDK release. This integration maintains consistency with Expo's recommended practices for dependency management within your project.
How does Atlas handle code formatting after a migration?: Atlas can be configured to run `prettier` on the diffs it generates. This ensures that any code changes made during the migration, whether in `app/` components or config plugins, adhere to your project's established formatting standards, maintaining code consistency in your Expo codebase.
Can Atlas help with config plugins for native capabilities in Expo?: Yes, Atlas can be asked to add native capabilities through a config plugin rather than requiring manual edits to `ios/` and `android/` directories. This ensures that your prebuild process remains reproducible and aligns with Expo's approach to managing native project configurations.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Migrate a Deprecated API Across Every Callsite with Atlas (2026 Workflow)

How to migrate a deprecated API across every callsite with Atlas in 2026: the lsp tool's findReferences enumerates callers, todowrite tracks them, apply_patch migrates each one.

Atlas for Expo: Terminal-Native AI Coding for expo-router and Config Plugins in 2026

Atlas is a terminal-native AI coding agent for Expo apps in 2026, covering expo-router file routes, config plugins, and EAS build profiles with diff-first review.

Review a Pull Request in Expo with Atlas in 2026

Streamline your Expo pull request reviews in 2026 with Atlas, the terminal-native AI agent. Catch subtle bugs by leveraging Atlas to inspect diffs, run jest-expo tests, and format code with prettier.

Run Atlas Headless in CI for Expo Projects in 2026

Automate Atlas in your Expo CI/CD pipelines by 2026. Get machine-readable output for `jest-expo` and `prettier` tasks, ensuring reproducible builds with `npx expo install`.

Extract a shared helper from duplicated code in Expo with Atlas in 2026

In 2026, use Atlas to find and refactor duplicated logic across your Expo codebase. Consolidate redundant code into a single, tested helper using Atlas's precise tools and Expo's native workflow.

Plan a Multi-File Change in Expo with Atlas in 2026

Design complex, multi-file changes for your Expo app in 2026 using Atlas. Plan and get review before modifying a single line, leveraging `jest-expo` and `prettier` for a safe workflow.

Document a module with a README in Expo with Atlas in 2026

In 2026, Atlas helps Expo developers create accurate READMEs for modules. It uses lsp, read, and codebase_search to document current code behavior, ensuring documentation reflects reality.

Debug a single failing test in Expo with Atlas in 2026

Pinpoint and fix failing `jest-expo` tests in your Expo application using Atlas, the terminal-native AI coding agent. Leverage Atlas's `lsp` and `bash` tools for precise debugging.

Browse this resource hub