TypeScript共享库如何无需深路径导入子模块的导出内容

通过给共享包配置标准的子路径导出规则，彻底替代@project/shared/src/xxx这类深路径导入，同时保留清晰的导入路径语义。

操作1：配置共享库的package.json导出规则 #

这是现在Node/TS生态通用的实现方式，不需要额外装第三方依赖。
在@project/shared包的根目录package.json中，补充exports字段做路径映射（原有的main、types等根入口配置保持不变即可），配置示例：

{
  "name": "@project/shared",
  "version": "1.0.0",
  "main": "dist/index.js",
  "module": "dist/index.mjs",
  "types": "dist/index.d.ts",
  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/index.mjs",
      "require": "./dist/index.js"
    },
    "./modules": {
      "types": "./dist/modules/index.d.ts",
      "import": "./dist/modules/index.mjs",
      "require": "./dist/modules/index.js"
    }
  }
}

注意：exports字段开启后会严格限制可导入的路径，原来直接指向src目录的深路径导入会被自动拦截，完全符合规避深路径的需求。

操作2：适配业务服务的TypeScript路径配置 #

如果是Monorepo环境下通过workspace链接共享包，需要在service-A、service-B的tsconfig.json的compilerOptions.paths中补充对应的路径映射，避免TS类型识别异常：

{
  "compilerOptions": {
    "paths": {
      "@project/shared": ["路径指向shared包的dist/index.d.ts"],
      "@project/shared/modules": ["路径指向shared包的dist/modules/index.d.ts"]
    }
  }
}

最终使用方式 #

配置完成后，业务侧的导入写法会变成完全无深路径的形式：

• 原有主入口的导入逻辑不受任何影响：import { someUtils } from '@project/shared'
• 引入module1的导出内容时，直接使用短路径：import { module1Variable } from '@project/shared/modules'

常见踩坑提醒 #

• 构建共享库时，要确保打包流程会将modules目录下的TS文件正常编译输出到dist目录的对应位置，不能只编译根入口文件，否则运行时会出现文件找不到的报错。
• 本地开发时如果不想每次改完shared库都重新构建，可以把tsconfig里的路径映射直接指向shared的src目录，比如"@project/shared/modules": ["../shared/src/modules/index.ts"]，开发体验会更流畅。
• 如果不需要区分导入粒度，也可以直接在共享库根级的src/index.ts中把modules目录的导出一起重导出：

  // shared库根级src/index.ts
  export * from './utils'
  export * from './logger'
  export * from './modules'
  

  这种写法不需要配置子路径映射，业务侧直接从@project/shared就能拿到所有导出内容，缺点是无法对modules部分做按需拆分，会让主入口的包体积变大。

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