React Native示例App软链接自定义模块时AsyncStorage无法正常生效问题

针对当前示例应用无法检测并链接模块原生依赖的问题，可选择以下任意一种方案解决：

• 方案1：示例应用显式安装依赖
  直接在示例项目根目录执行安装命令：

  npm install @react-native-community/async-storage@^1.12.1
  

  安装完成后重新执行pod install即可。RN 的 autolinking 机制默认仅扫描当前宿主项目dependencies中声明的原生模块，不会递归扫描本地依赖的子 node_modules 目录，显式安装后 autolinking 可正常识别到该依赖完成链接。
• 方案2：修改配置支持扫描模块目录的依赖
  调整示例项目的两处配置，让工具链可以识别到自定义模块下的依赖：
  1. 编辑metro.config.js，新增模块下 node_modules 的扫描路径：

  const path = require('path');
  module.exports = {
    resolver: {
      nodeModulesPaths: [
        path.resolve(__dirname, 'node_modules'),
        path.resolve(__dirname, '../node_modules')
      ]
    }
  }
  

  2. 编辑 ios 目录下的Podfile，给use_native_modules!传入自定义模块的路径参数：

  use_native_modules!([path.resolve(__dirname, '../')])
  

  修改完成后重新执行pod install和 metro 启动命令即可。
• 方案3：改用 monorepo 管理项目
  采用 yarn workspaces / pnpm workspace 管理自定义模块和示例项目，依赖会统一提升到根目录的 node_modules 下，autolinking 可正常识别所有原生依赖，适合长期维护的开源/内部模块项目。

将带原生代码的 RN 依赖声明为peerDependencies确实是 React Native 模块开发的标准实践。
RN 原生模块的代码最终需要编译链接到宿主应用的原生工程中，若你将原生依赖放在模块的dependencies中，很容易出现宿主应用和模块依赖不同版本原生模块的情况，导致重复链接、编译冲突、运行时报错等问题。
peerDependencies的核心作用就是要求宿主应用统一安装对应版本的依赖，保证整个项目中仅存在一份原生模块的代码，避免版本冲突，这个场景完全符合 peerDependency 的设计逻辑。通常模块会同时在devDependencies中声明该依赖，供本地开发、单元测试使用。

内容的提问来源于stack exchange，提问作者Adam Jenkins