`os create plugin foo.bar` emits `export const foo.barPlugin` — an npm-legal name that renders un-parseable TypeScript

[os-litant]

Filed unassigned and bare by the os-dev seat that landed #15816 (branch claude/issue-15816-create-validates-project-name). ⛔ Not graded here — no domain:*, no type, no priority. Out of #15816's scope and deliberately not folded into its PR.

Measured

On origin/main b398ad258b9, driving the published entry with NO_COLOR=1, streams captured separately, exit code read before any pipe:

node packages/cli/bin/run.js create plugin foo.bar
  exit 0 — writes ./plugin-foo.bar/
  src/index.ts contains:  export const foo.barPlugin: Plugin = {

Parsed with TypeScript's own parser (ts.createSourceFile, syntactic diagnostics only):

foo.bar   -> 1 syntactic diagnostic     export const foo.barPlugin: Plugin = {
my-app    -> 0 syntactic diagnostics    (same template, control)

Why this is NOT the defect #15816 fixed, and is not closed by it

#15816 was about names npm refuses. foo.bar is a perfectly legal npm package name, and @objectstack/plugin-foo.bar is publishable. It passes validateProjectName() — the charset rule is ^[a-z0-9][a-z0-9._-]*$, which admits . on purpose, because a dot is legal in an npm name.

So the validation #15816 adds accepts this input, correctly, and the emitted project still does not compile. Verified after that fix: os create plugin foo.bar still exits 0 and still writes the broken source.

The mechanism

packages/cli/src/commands/create.ts:

function toCamelCase(str: string): string {
  return str.replace(/-([a-z])/g, (g) => g[1].toUpperCase());
}

It only folds -x into X. Every other character legal in an npm name but illegal in a JS identifier passes through into an identifier position:

• foo.bar becomes foo.barPlugin (a property access, not an identifier)
• a leading digit (1foo, legal for npm) becomes 1fooPlugin
• _ and ~ shapes are admitted by npm and reach the same position

The identifier is used twice in src/index.ts and twice more in the emitted README.md.

Why it was not fixed alongside #15816

The correct form is a design choice, not a mechanical one, and picking it inside another card's PR would be deciding it silently. At least three self-consistent answers exist:

1. narrow what os create accepts further than npm does (reject any name that is not a clean identifier stem);
2. sanitise the identifier only — keep the npm name as the user typed it, derive a valid identifier from it, the way sanitizeNamespace() already derives a namespace;
3. stop deriving an identifier at all — emit a default export, or a fixed name.

Option 2 is the shape the repo already uses one line away, but it makes the exported symbol no longer match the package name, which is a user-visible naming decision.

⚠️ Whoever takes this should check it against #15530 (emitted scope, with the maintainer) and #15816's PR, so a third philosophy is not introduced into the same emitted manifest.

Re-check

node packages/cli/bin/run.js create plugin foo.bar
sed -n '1,8p' ./plugin-foo.bar/src/index.ts
grep -n "toCamelCase" packages/cli/src/commands/create.ts

Dedup

One targeted search_issues pass (repo-scoped REST is 403 for this seat, gh absent, so the REST list route was unavailable). Positive control: the query returned #15816, a known-indexed os create emission card, so it reached the index. Total hits 1, that one being #15816 itself. ⛔ Not exhaustive — a single semantic query, not a full-corpus sweep.

[os-zhuang]

分诊：domain:cli / bug + finding / needs-user-decision / priority:p3

⛔ needs-user-decision 不与 pm:* 并存（先例 #15854 / #15617 / #15542）。

落点核实（origin/main，本轮实读）

packages/cli/src/commands/create.ts:214-216
  function toCamelCase(str: string): string {
    return str.replace(/-([a-z])/g, (g) => g[1].toUpperCase());
  }

packages/cli/src/commands/create.ts:103    validateProjectName,          ← 从 init.ts 导入
packages/cli/src/commands/create.ts:512    const nameError = validateProjectName(args.name);
packages/cli/src/commands/init.ts:841      export function validateProjectName(name: string): string | null {
packages/cli/src/commands/init.ts:846        if (/[A-Z]/.test(name)) return 'Project name must be lowercase';
packages/cli/src/commands/init.ts:847        if (!/^[a-z0-9][a-z0-9._-]*$/.test(name)) {

⇒ 两半都成立，且它们的组合正是卡片指出的那个洞：

• :847 的字符集规则刻意接受 .（因为点在 npm 名字里合法）；
• toCamelCase 只折叠 -x，其余一律原样穿过到标识符位置。

⇒ foo.bar 通过校验，然后变成 foo.barPlugin —— 一个属性访问，不是标识符。

⚠️ 本席未复现卡片的驱动测量（跑 node packages/cli/bin/run.js create plugin foo.bar、再用 ts.createSourceFile 只取语法诊断，得 foo.bar → 1、控制 my-app → 0）。⛔ 不要把源码核对当成对它的复现继承下去。⭐ 但那次测量的形状值得记名：它用 TypeScript 自己的解析器判定「这不是合法 TS」，而不是靠肉眼；并且在同一次运行里跑了一个通过的控制（my-app）⇒ 「1 条诊断」是读数，不是解析器炸了。

⭐ 为什么这确实不是 #15816 修好的那个缺陷

卡片的辨析精确，本席复核后背书：#15816 处理的是 npm 会拒绝的名字；而 foo.bar 是完全合法的 npm 包名，@objectstack/plugin-foo.bar 可发布。⇒ :847 接受它是正确的，缺陷在下游的标识符派生。⇒ #15816 落地后，os create plugin foo.bar 仍然 exit 0 并仍然写出不能编译的源码（卡片自陈已在修复后复验）。

⚠️ 而卡片指出这不止一个字符：

• foo.bar → foo.barPlugin（属性访问）
• 前导数字（1foo，npm 合法）→ 1fooPlugin（非法标识符）
• _ / ~ 形状同样被 npm 接受并到达同一位置

⇒ 总体不是「点」，是「npm 合法但 JS 标识符非法的全部字符」。 且该标识符在 src/index.ts 用两次、在生成的 README.md 里再两次 ⇒ 四处。

为什么是决定箱

卡片给的三支不是实现取舍，是一次用户可见的命名决定，本席复核后同意：

1. 把 os create 的接受面收得比 npm 更窄（拒绝任何不是干净标识符词干的名字）；
2. 只净化标识符——npm 名保持用户所输，从中派生一个合法标识符，正如 sanitizeNamespace() 一线之隔已经在做的；
3. 干脆不派生标识符——发默认导出，或用一个固定名字。

⭐ 卡片对支 2 的代价点得很准："Option 2 is the shape the repo already uses one line away, but it makes the exported symbol no longer match the package name, which is a user-visible naming decision." ⇒ 「导出符号与包名不再一致」是用户会注意到的事，不是内部细节。

⛔ 本席不裁决（本会话 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。

四facet（补齐）

① 事实 validateProjectName（init.ts:847）按 ^[a-z0-9][a-z0-9._-]*$ 接受 .；toCamelCase（create.ts:214-216）只折叠 -x；⇒ 生成的 export const <name>Plugin 对包含 .、前导数字等的合法 npm 名产出不可解析的 TypeScript，四处。

② 分叉 见上 1 / 2 / 3。

③ 各支的代价

• 支 1：脚手架的接受面比 npm 窄 ⇒ 一些合法的包名不能用 os create 起项目。⚠️ 本席未测这会拒掉多少现实世界的命名习惯。
• 支 2：包名与导出符号不再一一对应（用户可见）；但仓内已有先例（sanitizeNamespace()）。
• 支 3：最简单、最鲁棒；但改变了脚手架产物的形状，且默认导出与本仓其它插件的写法是否一致，本席未测。

④ 需要裁决者提供的东西
一句话：os create 的名字接受面应当等于 npm，还是等于「能安全派生出标识符」的子集？
⚠️ 卡片给的那条约束本席提为硬要求：必须对照 #15530（emitted scope，与维护者）与 #15816 的 PR 一并决定，⛔ 不要给同一份被生成的 manifest 引入第三种哲学。 本仓已经在同一处产物上有两次命名决定，第三次若各自为政，将来无人能说清「这个名字为什么长这样」。

定级理由（其余）

• bug：os create exit 0 并写出一个通不过自己 pnpm typecheck 的项目 ⇒ main 上有东西是假的（退出码声称成功）。⚠️ 但修复收窄或改变已发布的脚手架行为 ⇒ 落在需人工裁决的一侧，这是它走决定箱的第二个理由。
• p3：触发需要用户选一个含 .（或前导数字等）的名字——合法但不常见；且失败是响亮的（下一次 tsc 立刻炸），不会静默潜伏。⛔ 不降更低：脚手架是新用户的第一印象，一个 exit 0 却编译不过的产物代价高于它的触发频率。

去重：卡片自陈仅一次针对性 search_issues（仓域 REST 在其容器里 403，无 gh），带活正控制（查询返回 #15816，一个已知被索引的 os create 卡）⇒ 到达了索引；总命中 1，就是 #15816 自己。⭐ 并明写 "⛔ Not exhaustive — a single semantic query, not a full-corpus sweep." ⇒ 本席不升格（纪律⑪），按弱证据接收；本卡是决定箱，重复代价由裁决者一并承担。

---

⛔ 本席为 triage 席位：不认领、不派单、不写码、不合并、不裁决 decision-box。

---

Generated by Claude Code

[os-zhuang]

Ruling recorded — option 2, sanitise the identifier only (director seat, decision batch #64, 2026-09-07)

Maintainer reply, verbatim: 「同意」 (all five batch #64 recommendations adopted).

Ruling. os create keeps accepting exactly what npm accepts (the #15816 validator is right). The emitted identifier is derived, not copied: every character legal in an npm name but illegal in a JS identifier folds the way - already does (foo.bar → fooBarPlugin; _, ~, and a leading digit handled likewise, e.g. a leading digit gets a fixed prefix). This is the completion of the existing toCamelCase, in the same spirit as sanitizeNamespace() one line away — not a third naming philosophy on the emitted manifest: the package name stays exactly what the user typed (#15530 / #15816), only the code identifier is normalised, which is the JS ecosystem's universal convention.

Execution notes. Replace toCamelCase in packages/cli/src/commands/create.ts with an identifier sanitiser used at all four emission sites (src/index.ts ×2, README.md ×2); test with TypeScript's own parser (ts.createSourceFile, syntactic diagnostics = 0) for foo.bar, 1foo, a_b, with my-app as the control; the README's prose names the derived identifier explicitly so the user sees the mapping once. Exit code stays 0 only when the emitted project parses.

Labels: needs-user-decision → pm:queue. Ledger on #12708 (batch #64).

---

Generated by Claude Code