我正在玩 Yarn 2，我想做这样的事情。
我有一个结构的monorepo：
/
packages/
shared-ts/
package.json
src/
lib*/
app-ts/
package.json
src/
lib*/
app-js/
package.json
src/
lib*/
wherelib*表示该文件夹是 gitignored，但它是编译代码所在的位置。
在此示例中，我有一个shared-ts由两个应用程序使用的依赖库，app-ts并且app-js.
常规方法
像这样配置 monorepo 的传统方法是，shared-ts我将有一个 package.json，如下所示：
"main": "lib/index.js"
"scripts" : {
"build": "tsc"
}
build脚本将在哪里构建index.js并index.d.ts进入 lib 文件夹。
当两者都app-ts解析app-js包时，他们会查看 lib 文件夹并找到index.jsand 在app-ts这种情况下 - index.d.ts.
这很好用，只是开发人员需要记住build如果他们进行了更改则运行脚本shared-ts，以便更改传播。
这可能会成为问题的地方是存在多层依赖关系。
尝试过 1 点main到src/index.ts.
我可以将shared-tspackage.json 更改为
"main": "src/index.ts"
"scripts" : {
"build": "tsc"
}
这通常不起作用，普通节点进程将无法解析.ts文件中的语法（例如import关键字）。
潜在的解决方法 -publishConfig
所以我正在考虑，但还没有尝试过的是，使用publishConfig
package.json 中的字段
此字段包含仅在从本地源（通过 yarn pack 或诸如 yarn npm publish 之类的发布命令之一）生成包时才考虑的各种设置。
"main": "src/index.ts",
"publishConfig": {
"main": "lib/index.js"
}
这个想法是：
- 当您将包发布到 npm 时，
lib/index.js将用作 main。代码已准备好使用，无需编译。 - 如果直接在 monorepo
src/index.ts中使用，将用作 main。例如，这种工作就像您正在运行app-ts一样ts-node。
但是，这开始崩溃的地方是：
- 在开发环境中运行
app-js（您没有设置任何额外的语法解析）。
实用的当前最佳解决方案
我目前最好的解决方案是“放弃这种‘不编译’的愿望”——如果开发人员对某些代码进行了更改，他们需要重新运行构建以使更改传播。
