Typescript 项目引用：处理引用项目的第三方依赖项

我有一个包含 3 个目录的项目client, api, and shared. The shared目录包含 typescript 类型和定义engine我想与之共享的文件夹client and api。此外，shared目录还需要一些第三方依赖项（在其 package.json 文件中指定）。

可以找到描述此场景的非常基本的示例存储库here https://github.com/priyath/typescript-shared-example/tree/project-references，在分支下project-references。本质上，server.js in api将导入并调用一个函数Entity.ts类又依赖于外部库（mathjs）。

现在我一直在尝试使用项目引用（相当不成功！）来构建我的api（我还没有研究过客户端！）以便共享代码可以在dist文件夹内的api用来。

到目前为止我所做的：

1. 我添加了以下内容tsconfig.build-api.json文件到shared目录。这outDir指向一个dist里面的文件夹api。这个想法是将编译后的共享文件移动到 api 的dist文件夹，保持相同的目录结构dist这样我的进口就不会损坏。同样，我计划为客户端提供另一个 tsconfig 文件。

{
  "compilerOptions": {
    "lib": ["es2015", "es2017", "dom"],
    "module": "commonjs",
    "target": "es6",
    "declaration": true,
    "declarationMap": true,
    "composite": true,
    "moduleResolution": "node",
    "outDir": "../api/dist/shared"
  },
  "include": ["engine"],
  "exclude": ["node_modules", "lib"],
  "references": []
}

2. 我已经更新了 apitsconfig.json文件来引用共享目录的tsconfig.build-api.json file

{
  "compilerOptions": {
    // some options
    "outDir": "dist/api/src",
  },
  "references": [
    { "path": "../shared/tsconfig.build-api.json" }
  ],
  // some more options
}

3. I run tsc --build .从里面api创建一个目录dist文件夹中包含已编译的 api 和共享代码。但是，当我尝试运行此构建代码时，我收到一条错误，指出shared找不到代码。

如何确保我引用的项目的第三方依赖项（shared）已解决，内部没有任何问题api?

注意：如果我的共享代码中没有第三方依赖项，我只需使用相对路径来执行所需的导入，就可以在没有项目引用的情况下完成所有这些工作。蒂乌被解释了here https://stackoverflow.com/questions/67031698/my-approach-to-share-typescript-code-between-cra-and-backend-am-i-missing-anyth。然而，由于外部依赖，我仍然无法找到一种方法来做到这一点。研究导致了诸如单一存储库、learana、yarn 工作空间等的出现。但我认为这可以在不依赖外部工具的情况下解决。

我必须解决同样的问题，经过几天的绞尽脑汁并使用我在网上可以找到的任何东西，这是我认为可以正常工作的唯一解决方案。它相当脆弱，因为它需要非常仔细平衡的文件夹结构才能工作。

我将使用客户端-服务器通用范式进行讨论，client和server取决于common项目。让我们从最顶层的“解决方案”文件夹开始。

除了其他设置外，还需要tsconfig.json（以确保 TSC 构建两个依赖项目）：

"references": [
  {
    "path": "./client"
  },
  {
    "path": "./server"
  },
 ]

And a package.jsonwith（以确保运行的代码能够加载公共模块）：

"imports": {
  "#common/foobar": "./out/common/src/foobar.js"
},

这俩client和server包需要一个tsconfigwith -- 确保它们输出到一个公共的out文件夹，以帮助 TS (IDE) 找到通用模块并在构建过程中依赖它：

"compilerOptions": {
  "baseUrl": ".",
  "rootDir": "../",
  "outDir": "../out",
  "paths": {
    "#common/*": [
      "../common/src/*.ts"
    ]
  },
},
"references": [
  {
    "path": "../common"
  }
],

这两个项目都可以使用并参考common在他们的源代码中为：

import { foobar } from '#common/foobar';

The common项目需要一个tsconfigwith （也可以输出到同一文件夹，并充当适当的TSC --build依赖项目）：

"compilerOptions": {
  "baseUrl": ".",
  "rootDir": "../",
  "outDir": "../out",
  "composite": true,
  "declaration": true,
  "declarationMap": true,
},
"references": []

最终的结果是一个共同点out在项目最顶层的文件夹中，其中包含三个子项目的子文件夹。如果需要，您可以从那里继续打包。

我发现如果outDir or rootDir文件夹具有任何其他结构，即使来自官方文档，整个方案也会崩溃。要克服的最大障碍是我们需要源代码（IDE 中的编译器和分析工具）和最终的转译代码来解决common模块。虽然我们使用相同的#common/foobar在这两种情况下，两者都有不同的底层机制：工具链使用tsconfig.json当运行代码使用package.json。虽然第一个允许我们查看项目文件夹根目录之外的内容（使用../）， 第二does not。这就是为什么我说你需要接受这一点out/*结构保持原样，并修改您的打包或运行需求以适应此文件夹结构，而不是相反：out三个子文件夹都可以工作，而三个子文件夹每个都有其out将不会。

最后，不要忘记在构建模式下调用 TSC：

"scripts": {
  "compile": "tsc -b",

外部依赖是根据具体情况而定，每个子项目都需要自己的依赖，最顶层的依赖package.json还需要其中的相关包node_modules.