Conversation
pnpm generation 布局将插件的全部依赖放在 <generation>/node_modules 下作为同级目录,而 componentManifest 只查插件内嵌与 profile 平铺两处, 兜底的 CJS require.resolve 对无 JS 入口的类型包(@types/*)以及 exports 不含 require 条件的纯 ESM 包必然失败,导致本机 dsh-better-sidebar → mermaid 的 35 个依赖被误报为 missing-client-module(blocking), normal mode 被永久卡在 safe mode。 新增 componentDirectory 三段解析(嵌套 → 平铺 → generation 同级), manifest 与 componentDir 统一复用同一路径;真正缺失的依赖仍保持原有 blocking 判定不变。 回归测试覆盖 generation 布局 + 无入口类型包不再误报、幽灵依赖仍报 缺失(修复前红、修复后绿),profile-compatibility 与 plugin-recovery-market 两个测试文件全部通过,tsc --noEmit 通过。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
问题
真机复现(DSH Desktop 0.9.2 / 内核
0.1.5-rc.2,Windows 11):安装dsh-better-sidebar后,inspectProfileCompatibility连续报出 35 个missing-client-module(severity: blocking),日志反复出现:normal mode 被永久卡在 safe mode,第三方插件全部被封禁。
被判定“缺失”的包全部来自
dsh-better-sidebar → mermaid的依赖(@types/d3*、@mermaid-js/parser、@chevrotain/types、@upsetjs/venn.js、@types/geojson等),但它们在磁盘上都存在:根因
generation 插件的真实目录是
<generation>/node_modules/<plugin>(pnpm 布局),其依赖全部是同级目录,既不嵌套在插件下、也不平铺在 profile 里。而componentManifest只查两处:pluginDir/node_modules/<pkg>— npm 嵌套布局profiles/web/node_modules/<pkg>— 平铺布局兜底
resolvesFrom用 CJSrequire.resolve(<pkg>)探测,对两类包必然失败:@types/*:无 JS 入口 →MODULE_NOT_FOUND@mermaid-js/parser/@chevrotain/types:exports不含require条件 →ERR_PACKAGE_PATH_NOT_EXPORTED于是“明明存在”的同级依赖被判为
not installed in this profile→ blocking → 永久 safe mode。本机实测(直接调用
inspectProfileCompatibility):对每个包单独验证:
require.resolve('@types/d3')从插件目录MODULE_NOT_FOUND,而dirname(pluginDir)/@types/d3/package.json存在。修复
新增
componentDirectory()三段解析:嵌套 → 平铺 → generation 同级(dirname(pluginDir)/<pkg>),componentManifest与componentDir统一复用同一路径。真正缺失的依赖行为不变——三处都找不到时仍回退到平铺路径,readManifest返回 undefined,原有 blocking 判定照旧。测试
accepts generation siblings for a pnpm-laid-out plugin instead of flagging them as missing:ghost-kit→ 仍报 blocking(防止过度抑制)test/profile-compatibility.test.ts:8/8 ✅test/plugin-recovery-market.test.ts:8/8 ✅tsc --noEmit -p tsconfig.node.json✅vitest run中另有若干失败(image-generation / feishu-release-notes / github-release-notes / ppt tar 路径 / generation-build-approval),均为 Windows 本地环境既有问题,与本改动无关(这些文件不引用 profile-compatibility)。关联
同类 generation false-positive 先例:#293