关于Prepare阶段收集依赖，能否做成可选配置（但依赖为monorepo workspace中的仓库，且该仓库未提前生成构建产物时，umi prepare会失败）

[MatrixAge]

尽管可以通过调整turbo的build flow顺序，但这一步其实是可以省略的，考虑到收集依赖会影响monorepo仓库的构建流程，所以建议做成可选配置。

[fz6m]

没遇到你说的这个问题，给个最小复现看下。

[MatrixAge]

https://github.com/YaoApp/xgen/blob/main/turbo.json
把 compile去掉，build不通过（未提前build依赖的情况下，因为主包xgen使用的storex是本地workspace中的），这个问题之前没有，更新umi之后出现的，应该是依赖收集的原因。

[fz6m]

看了一下，并不是 prepare 的问题。

1. 正常来说 monorepoRedirect 都是往别的包 src 去重定向的，但是你配置到了包根 srcDir: ['./'] ，如果是在 ./src ，就会按照常规文件来寻址，但 ./ 这个地方本来就是一个有 package.json 的目录，所以此时遵循了包的模块规范，要根据 package.json 里的 module / main 等字段声明来寻址，由于找不到产物 dist/index.js ，产生了报错。

   如何解决：子包的源码都放到 ./src 里，删去 srcDir: ['./'] ，不要让 package.json 影响解析。

2. 在其他子包使用 @/xxx 的别名写法，这是目前 monorepoRedirect 不支持的一种形式，因为当开启了重定向，这些第三方包的源码将和项目本身形成一体，此时的 @ 就是当前项目的 src 目录，不再是那个子包的 src 目录了，所以使用了这种写法的情况，不能使用 monorepoRedirect ，应该启动每个子包构建工具的 watch 模式，实时输出产物（这些产物里没有 @ 别名，因为被构建工具处理掉了），最后在主项目里配置 extraBabelIncludes: ['package-name'] 来做到热更新。

综上，只能取其一，选择 @ 的写法，就关闭 monorepoRedirect ，用 extraBabelIncludes 支持热更新，watch 模式支持实时构建。

或者选择 monorepoRedirect ，要求源码都放在 src 里，不使用 @ 的写法，子包里的导入全部换成相对路径。

[MatrixAge]

好吧，其实我想说的是依赖收集能不能做成可选，如果可选，关掉就行了，至于你说的上面这些，事实上一直也来也都是这么用的，没出过问题，上述解决方案都算不上是好的方案。我目前的做法的是去掉postinstall，在build前setup，然后在顶部turbo.json中加入一个compile预构建流程。