You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split out of #14527 by triage. #14527 is a one-line console.log deletion in packages/metadata; it noticed in passing that the sibling suppression comments beside it do nothing, and correctly declined to answer the wider question. This card carries that question, because it needs a ruling and must not block a trivial deletion.
--no-inline-config tells ESLint to ignore every inline configuration comment. So all 134 are inert under the repo's only lint invocation — not "inert because the rule they name isn't configured", but inert unconditionally, including the ones naming rules that are configured.
The concrete example that surfaced this: packages/metadata/src/plugin.ts:627,634,642,649,653 each carry // eslint-disable-next-line no-console, and no-console has zero hits in eslint.config.mjs. Two independent reasons for the same nothing.
Why it is worth a card
A suppression comment is a claim: this rule fires here, and we decided to allow it. A reader — human or AI — treats it as evidence that the line was considered and ruled on. 134 of those claims are false in this tree. The failure mode is quiet and in the wrong direction: someone deletes a disable comment expecting lint to go red, sees green, and concludes the code is clean; or adds one expecting a suppression, and gets one only by accident because nothing was firing anyway.
--no-inline-config is itself very likely deliberate and correct — it stops code from opting out of the gate, which is the strengthening choice. The defect is not the flag; it is 134 comments that contradict it.
Options
what it does
real cost
A
Delete all 134 inert comments; keep --no-inline-config
touches 45 files; noisy diff; must confirm lint stays green after each removal, since a comment naming a configured rule may be masking a real finding in some other invocation
B
Keep them, document the flag where an author would look, and add a gate refusing NEW eslint-disable comments
smallest diff; leaves 134 false claims in the tree
C
Drop --no-inline-config so the comments mean what they say
⛔ gate weakening — code regains the ability to opt out of lint, file by file, with no review of the opt-out. Human floor; listed for completeness, not recommended
What is NOT claimed
Not measured: whether any of the 134 names a rule that is configured and would fire — that determines whether option A is a pure deletion or uncovers real findings, and it is the first thing an implementer should run.
Not measured: whether any other lint invocation in CI omits --no-inline-config, which would make some of them live in that context only.
<!-- os-decision-facets -->
① 项目长远合理性(权重 ≥50%,领起推荐) —— 代码里有 134 处注释在声明「这里我们特意放行了某条规则」,而仓库唯一的 lint 调用从根上忽略所有这类注释。一个说法和事实长期并存地矛盾,就是最坏的一种契约增生 —— 它不增加功能,只增加读者的错误信念。长远终态只有两种自洽形态:注释有效(选项 C)或注释不存在(选项 A)。选项 B 是把矛盾永久留在树里,只在旁边贴一张说明。①指向 A —— 因为 C 是靠放开门禁来自洽,那是往错误方向缩特例。
Split out of #14527 by triage. #14527 is a one-line
console.logdeletion inpackages/metadata; it noticed in passing that the sibling suppression comments beside it do nothing, and correctly declined to answer the wider question. This card carries that question, because it needs a ruling and must not block a trivial deletion.Measured at
origin/mained44512package.json:32:--no-inline-configtells ESLint to ignore every inline configuration comment. So all 134 are inert under the repo's only lint invocation — not "inert because the rule they name isn't configured", but inert unconditionally, including the ones naming rules that are configured.The concrete example that surfaced this:
packages/metadata/src/plugin.ts:627,634,642,649,653each carry// eslint-disable-next-line no-console, andno-consolehas zero hits ineslint.config.mjs. Two independent reasons for the same nothing.Why it is worth a card
A suppression comment is a claim: this rule fires here, and we decided to allow it. A reader — human or AI — treats it as evidence that the line was considered and ruled on. 134 of those claims are false in this tree. The failure mode is quiet and in the wrong direction: someone deletes a disable comment expecting lint to go red, sees green, and concludes the code is clean; or adds one expecting a suppression, and gets one only by accident because nothing was firing anyway.
--no-inline-configis itself very likely deliberate and correct — it stops code from opting out of the gate, which is the strengthening choice. The defect is not the flag; it is 134 comments that contradict it.Options
--no-inline-configeslint-disablecomments--no-inline-configso the comments mean what they sayWhat is NOT claimed
--no-inline-config, which would make some of them live in that context only.<!-- os-decision-facets -->
MetadataPlugin.initprints a leftover debug probe on every boot — an undisabledconsole.logthree lines under thectx.logger.infoit should have been #14527 正是有人读到这些注释、以为旁边那行console.log是漏了标记,才顺手量出来的。零外部拉动 ⇒ 按分歧推荐序本该荐④不扩散,但见下:④在这里恰好也指向 A。推荐:A —— 删掉全部 134 条,保留
⚠️ A 有一个必须先量的前置条件(见上文「未测量」):这 134 条里若有指向已配置规则的,删掉它就可能露出真实告警。所以 A 的执行顺序是:先逐条量出哪些指向已配置规则、在别的调用下会不会触发,再删;露出的真实告警各自成卡,⛔ 不在这张卡里顺手修。
--no-inline-config。 ①③④同向,②零拉动在这里不构成反对,因为 A 本身就是「移除」而不是「新增」。回退:B —— 若维护者判定 45 个文件的改动面在当前节奏下不值得,则保留注释、把
--no-inline-config写进作者会看的地方,并加一道门禁拦住新增的 disable 注释,防止这个数字继续长。置信缺口(本分析看不见什么): 没有量 CI 里是否存在另一条不带
--no-inline-config的 lint 调用 —— 若有,则这 134 条在那个上下文里是活的,A 就从「删死代码」变成「改变 CI 行为」,推荐要重排。这是唯一能翻掉 A 的变量,本轮没量。另外 ⛔ 本席不碰选项 C:放开--no-inline-config让代码逐文件退出 lint,是门禁弱化,恒人工。Refs: #14527 (the split parent — the
console.logthat surfaced this).Generated by Claude Code