我的 monorepo 如下所示：
这是一个带有turborepo的yarn 3 monorepo，用于缓存构建资产。
在初始设置时，app1 直接使用 package1，中间没有构建步骤。这似乎是合理的，因为它们都住在同一个 monorepo 中。然而，大量的性能问题和数百条这样的消息：
@app1: [BABEL] Note: The code generator has deoptimised the styling of ... as it exceeds the max of 500KB.
@app1: [BABEL] Note: The code generator has deoptimised the styling of ... as it exceeds the max of 500KB.
...
@app1: [BABEL] Note: The code generator has deoptimised the styling of ... as it exceeds the max of 500KB.
导致我选择了另一条路线，即构建 package1 并在 app1 中使用它。到目前为止，这确实有所帮助，即使使用 package1 的构建版本，也会发生上述相同的行为。
我无法确定其根本原因。我最接近的假设是 Vite 对单一存储库的配置错误，但在研究选项时我没有太多运气。
导致 app1 在此设置中出现性能问题并输出上述许多警告的潜在原因是什么？
您遇到的问题，特别是“代码生成器已取消优化...的样式，因为它超过了 500KB 的最大值”警告，表明 Babel 必须处理非常大的文件。 500KB 限制是为了防止性能问题；超过它会减慢 Babel 的速度，甚至可能减慢你的整个构建过程。
鉴于您正在使用 Vite、TypeScript 和 monorepo 设置，问题可能来自多个方面：
Monorepo 符号链接：在 monorepo 中工作时，包链接有时会使 Babel 和 Webpack 等工具表现不同，将链接的包视为主包的一部分。这可能会导致捆绑和转译的代码比您预期的多得多。
Tree Shaking：如果使用的包（或多个包）非常大并且没有针对 Tree Shaking 进行很好的优化，则可能会导致导入比实际需要的代码更多的代码。这也会加剧大小限制问题。
捆绑配置：使用Vite，确保正确标记外部依赖并正确优化内部包。 Vite 有自己的处理常见 JS 和 ESM 包的方式，这在 monorepo 设置中可能会发生冲突。
共享依赖项：在单一存储库中，如果依赖项未正确提升或共享，有时可能会导致相同代码的重复副本，从而增加捆绑输出的大小。
包转译：如果您构建了 package1 以针对更旧版本的 JavaScript（例如 ES5），它可能会生成更大的代码，当 app1 使用时，它会超出大小限制。
一些解决方案： 优化依赖关系：确保只导入实际使用的代码。这将使 tree-shaking 更加有效。
检查构建输出：查看构建输出以识别任何异常大的文件或依赖项。尝试理解为什么它们很大以及它们是否可以分解或延迟加载。
Vite 和 TypeScript 配置：确保 Vite 和 TypeScript 配置正确，尤其是它们如何解析 monorepo 中的模块。 Vite 有一个resolve.alias 配置选项，可以很有帮助。 检查 Package1：组件库本身（package1）可能需要优化。想办法让它变小或者把它分成更小的块。
Turborepo 缓存：确保 Turborepo 正确缓存您的构建资源，并且不会间接导致这些较大的构建大小。 调查警告：通过增加紧凑选项限制可能会消除警告，但不建议这样做，因为潜在的性能问题仍然存在。