为何Expo的tsconfig.base使用moduleResolution: node而非node16？

方案1：调整模块解析策略兼容exports配置 #

不需要放弃分模块导出，你可以在共享库的tsconfig.json中单独设置更现代的模块解析规则，同时确保Expo项目能兼容：

// 共享库的tsconfig.json
{
  "compilerOptions": {
    "moduleResolution": "bundler", // 或 "nodenext"，两者都支持package.json exports
    "module": "ESNext",
    "target": "ESNext"
  }
}

同时在Expo项目的tsconfig.json中，也将moduleResolution改为bundler——这是Expo最新版本推荐的配置，既能支持exports，也不会影响原有项目的构建。

方案2：添加Legacy兼容字段，让exports和Node解析共存 #

如果必须保留Expo的moduleResolution: node，可以在共享库的package.json中添加条件导出和兼容字段，同时生成编译后的产物：

// 共享库package.json
"name": "@foo/api",
"exports": {
  "./auth": {
    "import": "./src/auth.ts",
    "require": "./dist/auth.js"
  },
  "./config": {
    "import": "./src/config.ts",
    "require": "./dist/config.js"
  },
  "./user": {
    "import": "./src/user/index.ts",
    "require": "./dist/user/index.js"
  }
},
"main": "./dist/index.js",
"typesVersions": {
  "*": {
    "auth": ["./dist/auth.d.ts"],
    "config": ["./dist/config.d.ts"],
    "user": ["./dist/user/index.d.ts"]
  }
}

这样Node解析时会使用require对应的编译后路径，而现代工具也能识别exports的配置。需要注意先通过tsc将源码编译到dist目录。

方案3：用路径映射绕过Node解析限制 #

在Expo项目的tsconfig.json中添加paths配置，直接映射子模块的路径：

// Expo项目的tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "@foo/api/auth": ["../path-to-your-api-library/src/auth.ts"],
      "@foo/api/config": ["../path-to-your-api-library/src/config.ts"],
      "@foo/api/user": ["../path-to-your-api-library/src/user/index.ts"]
    }
  }
}

这种方式不需要修改共享库的配置，直接让Expo项目通过路径映射找到对应的模块文件。

备选：单文件导出+main配置 #

如果上述方案都嫌麻烦，改成单文件导出也可行——在共享库根目录创建一个index.ts，导出所有子模块的内容：

// src/index.ts
export * from './auth';
export * from './config';
export * from './user';

然后在package.json中设置：

"main": "./src/index.ts",
"types": "./src/index.ts"

但这种方式会丢失按需导入的能力，可能导致打包体积增大，适合模块数量少、体积小的场景。

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