AIexpo增长react-nativeSDK 升级

Hipcamp 如何借助 Claude Code 升级 Expo SDK 版本

从季度到冲刺：Hipcamp 如何用 Claude Code 升级 40 多个 React Native 依赖、迁移到新架构，并在 Expo 54 上发布。

Expo BlogArmaiz Adenwala6 分钟阅读

中文
中文日本語
复制
How Hipcamp upgraded Expo SDK versions with Claude Code

本文由 Armaiz Adenwala 撰写——Armaiz 在 Hipcamp 负责移动端应用体验。

…

升级 React Native 向来是让工程师头疼的事。你得碰不熟悉的原生代码、关键依赖库，还要处理破坏性变更。只要测试不够彻底，任何地方都可能报错。后来 React Native Upgrade helper 这类工具让流程轻松了一些，Expo 这类框架的出现也是为了让升级更顺畅。

升级的复杂度

可惜不是每个 React Native 应用都处在理想状态。对节奏快的公司来说，一边维护依赖一边交付功能，本身就很难平衡。结果就是升级变成一项大工程。Hipcamp 最近就碰上了升级到 New Architecture + Expo 54 的挑战。在 New Architecture 下，我们有几十个库已经过时，要么升级，要么替换。

只要在 React Native 上做过足够多的活，你就知道单纯把版本号升到最新远远不够。大量时间会花在调试和解决问题上。而且多个库之间可能互相冲突，你还得找出彼此兼容的版本。

好在这次我们已经有了 Scout——一个 AI agent，专门用来啃我们丢给它的任何任务。换成工程师来做，得花好几周做枯燥的依赖调研和版本协调，而 Scout 只用了几天、几个集中的会话就搞定了。虽然内部有 Scout 这样的 agent 很省事，但我们还是会分享如何只用 Claude Code 完成 React Native 升级。

Scout 加速了 Hipcamp 的升级

升级前的 Hipcamp 应用状况

除了安全更新，我们并没有认真跟进应用的版本迭代。被弃用的包、四五年前甚至六年前的旧包，比比皆是。我们有 100 多个依赖，其中大约 40 个需要升级才能支持 New Arch。

公司人手本来就紧，除了日常产品开发，我们根本没有余力兼顾升级。这不是钱的问题，是时间的问题。我们没法说服自己把一个工程师从有影响力的项目上抽走，去做这项耗时几个月的大升级。

如何界定升级范围

在深入讲我们如何完成这次升级之前，得先谈谈这个流程的核心目标，因为这决定了提示词该怎么设计。

我们最终定下了几条：

  • 只处理真正需要的依赖

    • 只升级那些目前还不支持新架构 / 16kb Android 的库

  • 用 Expo 的对应模块替换依赖

    • Expo 的模块维护得好、可靠，用的人也多。

  • 把 patch-package 当作最后手段

升级流程

接着我们决定了这次升级该怎么推进，结论是需要分多个阶段来做。

每个阶段愿意投入多少时间、多少钱，得先想清楚。最终我们意识到，token 的成本远低于让一个工程师不知疲倦地翻文档、读代码、查 GitHub issue。更何况，工程师省下来的时间都花在了能带来收入的产品功能上。所以让预算限制这个项目，根本不在考虑范围内。

阶段 1：构建你的 agent

我们强烈建议在内部构建一个类似 Scout 的 agent，或者直接用 Expo 的 upgrade skill。把代码库教给它，并设计一套索引代码库架构的方式。我们花了一天时间跑 documenter 命令 /scout-document-architecture，把应用的方方面面都记录下来。这样 Scout 就不会产生幻觉，也不会漏掉东西。

阶段 2：审计所有依赖

我们给 agent 派了个任务，审计全部依赖。建议用 sqlite 数据库来跟踪所有内容，这个数据库可以同步到你的项目管理工具，或者干脆用一个 markdown 文件。

然后我们给它提供了一段提示词。下面是我们当时用的示例：

# Expo SDK 50 → 54 Dependency Audit

Audit every dependency in the app for Expo 50 → 54 upgrade compatibility.

## Context
- **Current:** Expo 50 (RN 0.73, React 18.2)
- **Target:** Expo 54 (RN 0.81, React 19.1)
- Expo 52+ enables New Architecture by default
- Expo 52+ requires 16kb Android page size support

## Research
For each dependency, you MUST:
- **Read GitHub changelogs/releases** between the Expo 50 and Expo 54 compatible versions
- **Search GitHub issues** for bugs, errors, risks, complaints
- **Read setup docs** and migration guides
- **Check for conflicts** with other dependencies in our stack
- **Check if the setup switch is risky or complex**

Then answer:
1. Can this be **replaced with an Expo module**?
2. Can this be **removed entirely**?
3. Are there **known New Arch blockers** in GitHub issues?
4. Are there **16kb page size issues** reported?
5. Does this have **peer dependency conflicts** with other deps?
6. Is the **upgrade path smooth** or does it require code changes?
7. Are there **community complaints** about recent versions?

## Subagent Strategy
- **1 subagent** for small/simple JS-only dependencies
- **5 subagents** for medium/harder native dependencies
- **10 subagents** for extreme-complexity dependencies (react-native core, reanimated, maps, firebase, sentry)
- Each subagent works on exactly ONE dependency — do not batch

## Output
- One notes file per dependency in `./dependencies/{name}.md`
- SQLite DB at `./dependencies.db` with columns: name, expo_50_version, max_version_expo_50, expo_54_version, new_arch_support, sixteenkb_support, status, type (javascript/native), change_recommendation (upgrade/remove/swap), swap_target, complexity (0-10), notes
- **Always prefer replacing with an Expo equivalent library if possible**
- Process dependencies one at a time — do not skip ahead

## References
- https://reactnative.directory/
- https://docs.expo.dev/workflow/upgrading-expo-sdk-walkthrough/

阶段 3：审查并开始升级！

升级 SDK

之后，我们逐条人工过了一遍每个升级项，确认都没问题。确保它没有删掉不该删的库，如果它推荐了替代库，就挑出合适的那个。如果 Expo 的库里有现成的，我们强烈建议直接用，它们维护活跃、文档也齐全。

记录过程

完成后，我们派了一个 agent 去为每个升级创建 PR。对我们来说，第一轮跑下来是不间断升级了 3 天。处理长时间运行的任务时，我们强烈建议每一步都用 subagent。让每个依赖都有自己的 context，是升级可靠的关键。

我们给它的流程如下：

选一个依赖

派一个 subagent 查看上一步的笔记

让 1-3 个 subagent 尝试升级到指定版本

完成后，派 reviewer subagent 审查改动

运行 yarn lint、tsc 和 react native bundle，处理出现的错误

为 ios 和 android 创建 EAS build，确认构建成功。处理可能出现的错误

为 ios + android 创建最终的 EAS Build

创建 PR，附上构建产物、手动 QA 步骤、受影响的页面以及其他相关信息

等我回来时，已经有一堆 PR 等着我审。过完所有这些 PR 花的时间很少。当然有几个 PR 需要工程师深度参与，但上手很容易，因为 agent 已经在 PR 里把全部 context、文档、相关 Github issue 等等都整理好了。

从我们的经验看，只有一周时间花在调试 New Architecture 的一些构建问题上。整个升级流程从原本预估的 2-3 个月缩短到了几周。从一个季度变成一个 sprint。我们的依赖状况本来很糟糕，应用规模更小的话，你感受到的耗时可能更短。

当然还有一些收尾工作，但大头已经做完了。

阶段 4：QA、发布与监控

我们想要一次非常稳妥的发布，于是要求 Hipcamp 的同事都用这个 app 并报 bug。我们办了一场 QA party，公司的人聚在一起给 app 做 QA。这种活动效率极高。

之后我们用了 iOS 和 Android 的慢速发布功能。先发 iOS，等我们对 iOS 有信心后再发 Android。

监控：

必须有某种错误追踪机制，这一点至关重要。另外，把性能分析集成进 app 也是个好主意。这类工具很多，其中之一是 Expo Observe——我们很幸运能参与它的 private preview！

我们还让 agent 持续监控并修复出现的错误。无论是来自 QA 团队还是生产环境，agent 都能在工程团队几乎不介入的情况下解决大部分 bug。

出乎意料的是，除了一个在新架构上被放大的高内存占用问题之外，我们没有发现任何重大的新错误。事实上，错误总数反而更少了。我们认为原因在于：工程师可以把时间花在解决复杂问题和充分 QA 上，剩下的交给 agent 处理。

结论

AI 正在改变工程师的工作方式。花在翻阅文档、赶截止日期、调试冷门问题上的时间，可能很快就会成为过去。这次升级证明了 AI agent 可以是重要且高难度项目上可靠的伙伴，也证明了 AI 辅助工程的真正价值不是取代工程师，而是把他们解放出来，去专注解决复杂问题，而不是在繁琐的事务里消耗精力。

来源: Expo Blog← 返回首页