安装 Rust pnpm 引擎时总是重解: 状态依赖生成的列表和缺少的去dupePeers选项
作者: zkochan创建于 2026年7月29日更新于 2026年7月30日
- 生成的组件清单根据是否存在
node_modules而不同: Bit 的依赖检测会根据node_modules的存在生成不同的清单,对于相同的工作空间状态: - 存在node_modules时,生成的清单中包含@apollo/client@^3.12.0; - 不存在node_modules时,相同组件的清单中不包含它,尽管这三个组件在源代码中确实使用了@apollo/client。因此,引擎的锁文件新鲜度检查永远都不会结束。从引擎的过时日志中截取的内容(使用TRACE=pacquet::install=info): - 存在node_modules的安装,来自不存在node_modules的安装的锁文件:锁文件中的规范符不匹配 package.json 中的规范符: * 添加了 1 个依赖项: @apollo/client@^3.12.0- 存在node_modules的安装,来自存在node_modules的安装的锁文件:... * 移除了 1 个依赖项: @apollo/client@^3.12.0由于没有锁文件能够满足两种状态, **每次删除node_modules后的安装(以及之后恢复node_modules后的安装)都会进行全面重新解析(当前引擎需要 3-4 分钟时间),而不是使用冻结路径。修复此问题后,在温暖的工作空间中,引擎的冻结路径为 1 秒,在删除node_modules后,引擎的材料化时间为 5.5 秒 - 在resolved 0, reused N处出现的"卡顿"是全面重新解析,而不是存储/链接管道。预期的修复: 依赖检测/版本归属必须与安装状态无关,导入@apollo/client的组件应在存在或不存在node_modules时获得相同的清单项。 2.lynx.js不向引擎传递dedupePeers: trueBit 现有的锁文件记录了settings.dedupePeers: true(由之前的引擎集成生成)。scopes/dependencies/pnpm/lynx.ts中的当前installOptions不传递dedupePeers,因此引擎将其解析为默认值(即false),并报告其新鲜度门限:锁文件中的dedupePeers(true) 不匹配当前配置(false)→ 对现有 Bit 仓库的每次安装都被视为过时,进行全面解析,并重写整个锁文件的对等后缀(差异为 50k 行),然后继续不断变化。 到目前为止,这是无法从 Bit 方面修复的,因为@pnpm/napi安装选项…
内容来源: teambit/bit