React Native多应用代码共享及AsyncStorage空值问题咨询

• 作为React、React Native与NodeJS初学者，最初通过npm init创建Node共享模块，模块内编写基础样式按钮组件，通过npm pack打包后，在业务应用的package.json依赖项中通过file:../shared/_dist/shared-1.0.0.tgz本地路径引入包。
• 共享模块入口index.js代码如下：

import MyButtonFirst from './components/buttons/MyButtonFirst';
module.exports = { MyButtonFirst  };

• 业务应用中引入组件的代码如下：

import React from 'react';
import { MyButtonFirst } from 'shared';

export default function MySharedButton()
{
   return <MyButtonFirst />;
}

该引入方式可正常运行。

• 后续在共享模块中编写依赖react-native-async-storage/async-storage的组件（已在共享项目中执行npm install安装该依赖），升级版本、重新打包并在业务应用安装新版本后，Android端运行时出现AsyncStorage is null的报错。

1. AsyncStorage返回空值的原因是什么？是否需要在共享模块和业务应用两侧都声明该依赖？双侧声明虽可生效但不符合常规依赖管理逻辑，是否存在更合理的处理方式？
2. 如何在多应用间共享图标、图片这类静态资源？
3. 业务场景说明：需开发三款面向体育领域不同用户角色（运动员、裁判、场地管理员）的React Native应用，三者共用同一套API数据源，存在大量可复用代码，包括图标、用户/主题等上下文、错误处理逻辑、API调用封装等。不希望开发为带权限控制的单体大应用，而是拆分出面向不同角色的独立小型应用，需要多个React Native应用间共享代码的最佳实践方案。

1. AsyncStorage为null的原因与正确依赖配置方式 #

这个问题的核心原因是React Native原生依赖和纯JS依赖的解析逻辑存在本质差异：

• 你之前写的纯JS按钮组件能正常运行，是因为纯JS代码会被Metro打包器正常遍历解析，不受依赖嵌套位置的影响，但带原生代码的RN依赖不适用这套逻辑。
• 把react-native-async-storage/async-storage装在共享模块的dependencies里时，npm会把这个依赖装在共享模块自身的node_modules嵌套目录下，业务应用安装tgz包时会重复嵌套安装一份AsyncStorage。但React Native的Autolinking机制只会识别业务应用根目录node_modules下的原生依赖，嵌套的依赖不会被链接到原生工程，Android端运行时找不到对应的原生模块实例，就会返回null。
• 双侧都装依赖能生效的本质是业务应用根目录下有了这份依赖，可以被正常Autolinking，但这种写法会埋下版本不一致的隐患：如果共享模块和业务应用装的AsyncStorage版本不匹配，会出现更难排查的原生冲突。
• 正确处理方式是把所有React、React Native核心依赖，以及带原生代码的第三方RN依赖（比如AsyncStorage、导航库、原生UI组件库），全部放到共享模块的peerDependencies中声明兼容版本范围，同时在devDependencies里安装对应版本用于本地开发。共享模块package.json配置参考：

{
  "name": "shared",
  "version": "1.0.0",
  "main": "index.js",
  "peerDependencies": {
    "react": "^18.2.0",
    "react-native": "^0.72.0",
    "react-native-async-storage/async-storage": "^1.19.0"
  },
  "devDependencies": {
    "react": "^18.2.0",
    "react-native": "^0.72.0",
    "react-native-async-storage/async-storage": "^1.19.0"
  }
}

这种配置下npm不会在共享模块下嵌套安装这些依赖，只会强制要求业务应用在根目录安装符合版本要求的对应依赖，既满足RN原生依赖单例、可被Autolinking的要求，也符合依赖管理规范——共享模块本身不内置宿主环境必须提供的基础依赖，只声明自身兼容的版本范围。

2. 多RN应用间共享静态资源的方法 #

图标、图片这类静态资源不要直接打包进tgz用深层相对路径引用，容易出现打包时资源路径解析失败的问题，常用可行方案有两种：

• 方案一：在共享模块入口文件中统一导出静态资源引用，所有资源路径写相对于共享模块入口文件的正确路径即可，示例：

// 共享模块index.js
export { default as MyButtonFirst } from './components/buttons/MyButtonFirst';
// 导出图片资源
export const SportIcon = require('./assets/icons/sport.png');
export const DefaultAvatar = require('./assets/images/default-avatar.png');

业务应用中直接从共享包导入即可使用：

import { SportIcon } from 'shared';
<Image source={SportIcon} />

这种方式适合资源量不大的场景，Metro打包器会自动处理跨包的资源引用，不需要额外配置。

• 方案二：如果静态资源量很大（上百张图标、切图），可以把所有图标转为SVG组件统一在共享模块导出，SVG组件的使用和普通React组件完全一致，跨应用引用不会有路径兼容问题；也可以把静态资源单独抽成独立的资源包管理。

3. 多React Native应用共享代码的最佳实践 #

针对三个独立RN应用复用代码的场景，不要继续用npm pack打tgz本地引用的方式，长期维护成本极高，推荐按monorepo模式组织代码：

• 目录结构参考：

root/
├── apps/                # 三个独立业务应用
│   ├── athlete/         # 运动员端
│   ├── referee/         # 裁判端
│   └── manager/         # 场地管理员端
├── packages/            # 共享模块
│   ├── ui/              # 共享按钮、表单、通用业务组件
│   ├── assets/          # 共享图标、图片、主题变量
│   ├── api/             # 共享API请求封装、接口定义
│   ├── storage/         # 共享AsyncStorage封装、本地缓存逻辑
│   └── utils/           # 共享错误处理、通用工具函数
├── package.json
└── metro.config.js      # 配置Metro监听packages目录，支持跨包引用

• 用工作空间管理依赖（可选npm workspaces、yarn workspaces、pnpm workspaces），所有公共依赖提升到根目录node_modules统一管理，彻底解决原生依赖重复安装、链接失败的问题，也不需要手动打包tgz，修改共享模块代码后三个业务应用可以实时生效，省去反复打包、升版、重新安装的流程。
• 所有带原生依赖的共享封装，统一在共享包的peerDependencies声明对应依赖，由业务应用端统一安装、链接，避免原生版本冲突。
• 如果后续需要把共享模块提供给团队外的项目使用，再给对应packages配置构建流程，发布到私有npm仓库即可，不需要调整现有业务代码的引用逻辑。

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