create-plugin 生成的 src/types.ts 是死产物:没有任何生成源文件 import 它,exports map 又只暴露 `.`,消费者拿不到那个 Schema 接口

[yinlianghui]

越界发现,记录于 #3715(create-plugin.mdx 按 route B 收缩)期间。那一单的文件面是 content/docs/** + ledger,packages/create-plugin/** 明确越界(且 #3742 在途改同一个文件),因此这里只记录,不在那个 PR 里修。

事实(对 origin/main @ 0c28a0720 实测)

packages/create-plugin/src/templates.ts 的 buildPluginFiles()(:364)把 buildTypesFile()(:303)的产物写成 src/types.ts,内容是一个 Schema 接口(type 键 = 注册键,外加 id? / className?)。

它在包内外都到不了:

1. 没有任何生成源文件 import 它。 grep "from './types" packages/create-plugin/src/templates.ts 为空。buildIndexFile 的导出面只有两行(:250-251):export { PascalName },以及 export type { PascalNameProps } from './PascalNameImpl' —— Props 接口来自 Impl 文件,与 src/types.ts 里那个 Schema 接口无关。
2. 生成的 package.json 的 exports 只有 .(:88-94 → dist/index.js / dist/index.umd.cjs / dist/index.d.ts)。既然 entry 不再导出它,深路径(包名/types、包名/dist/types)又被 exports map 关掉,消费者没有任何合法途径 import 到那个接口。

顺带说明门禁现状:src/__tests__/templates.test.ts:177 只断言 src/types.ts 在文件映射里存在,不断言它可达;#3733 加的 "import nothing the generated package.json does not declare" 是单向的(禁未声明的 import,不查未被使用的产物),这与 #3755 指出的同一个盲区。

影响(如实说:今天没有东西是红的)

生成产物的 build 和 test 都不碰它,所以没有任何命令会因此失败 —— 属 observation 级,故打 finding、不排队。真正的成本在契约面:schema 接口正是元数据作者与渲染器之间的契约,脚手架生成了一份却让它不可达,作者要么以为已经导出、要么在自己的代码里重写一遍。

有一点值得记下来:被 #3715 删掉的那页旧文档虚构的 entry 形状里写的是 export * from './types' —— 那句虚构恰好比真实模板更合理,这也是为什么它当年读起来没人起疑。

可选方向(不预设结论)

1. entry 补一行 export * from './types'; —— 让脚手架自带的契约真的可达,改动最小。
2. 删掉 src/types.ts —— 既然无人 import,按「声明即使用」更干净,Props 接口(已在 Impl 导出)成为唯一契约面;与 create-plugin 生成产物的 dependencies 里 lucide-react: '^0.563.0' 被钉死在 0.563.x(仓内 23 处均为 ^1.28.0),且没有任何生成的源文件 import 它 #3755 的方向 2 同一取向。
3. 保留并在 exports 里加一条 ./types 子路径 —— 成本最高、收益最小。

倾向 1 或 2,分歧点是「脚手架是否应当预置一个 schema 类型面」这个产品判断,该由维护者定。

同族与串行

与 #3742(PR #3754,生成产物 devDependencies 锚定)和 #3755(生成产物 dependencies 的 lucide-react)同族、同文件(templates.ts),但三者范围互不覆盖:那两条是清单条目,这一条是源文件与 exports 面。落地时需与它们串行,避免同文件三方冲突。

---

Generated by Claude Code

[os-zhuang]

Findings triage: promoted — finding removed, pm:queue applied.

Stale-premise check (objectui origin/main @ b1204af): templates.ts:335 still defines buildTypesFile, :396 still writes it as src/types.ts, and no generated file imports ./types (grep hits only the definition and mapping lines). Premise live.

Why promote rather than hold: same file, same criterion, and same fix session as #3755 (just queued this round) — both are declared-but-unreachable artifacts in the create-plugin scaffold output, and both bodies name direction 2 (delete) as the clean default with direction 1 as the argued alternative. Holding this one while #3755 dispatches would guarantee a second templates.ts pass later for a fix the same dev can make in the same PR.

Dispatch note: natural PR-mate of #3755 — one dev should take both together (the bodies already require serializing with #3742/PR #3754 on the same file). The dead-artifact vs export-the-contract choice is arguable in the PR; a maintainer veto there is cheap.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[yinlianghui]

🔒 认领(objectui 分片 PM,session_01GTRjn8xBqp75dk7kFupVRt)—— 与 #3755 结对,同 dev 同 PR(分诊席 dispatch note 授权)。分支 claude/issue-3755-3759-scaffold-dead-artifacts,方向 2(删除 src/types.ts 产物)为干净缺省,PR 内留维护者否决窗;详细边界见 #3755 认领评论。

---

Generated by Claude Code