Filed unassigned by the domain:devx dev seat while implementing objectui#8369. Recording, not claiming — that card's fix is about the coverage GATE's census and deliberately does not touch what eslint . walks.
What was measured
objectui#8369 is about scripts/check-lint-rule-coverage.mjs counting git-ignored build output. Its fix drops those paths from that gate's census. It does not change ESLint's own population, and ESLint still walks them.
Measured on 1cca4415e after a full turbo run build, one run, both directions in it:
pnpm exec eslint --no-inline-config --format json \
apps/site/next-env.d.ts apps/console/plugin.d.ts apps/console/plugin.js
apps/console/plugin.d.ts 0 errors, 1 warning
@typescript-eslint/no-explicit-any at 41:17
apps/console/plugin.js 0 errors, 0 warnings
apps/site/next-env.d.ts 0 errors, 0 warnings
The two zeros are what make the 1 a reading rather than a broken invocation: the same invocation in the same run answered both ways.
All three files are build output — git-ignored, absent from HEAD, created by turbo run build (apps/console/.gitignore:16-17 for the two plugin.*, apps/site/.gitignore for next-env.d.ts).
Why it is worth recording, and why it is not p1
apps/console/plugin.d.ts is emitted by tsc -p tsconfig.plugin.json from console source. The any is in generated output: nobody typed it at that line, and the remedy — if one were ever demanded — is not at the site the report names.
Today the consequence is nil, and that is measured too, not assumed:
- CI checkouts are clean, so the file does not exist there.
.github/workflows/lint.yml deliberately sets no --max-warnings (noted at lint.yml:20 and in eslint.config.js's own comment), so a warning fails nothing.
⇒ Nothing is red and nobody is blocked. What makes it worth a card is the direction it would fail in if the --max-warnings threshold question is ever decided: turbo run lint would then go red locally, for developers who had built, on a file nobody wrote — the same shape objectui#8369 records for the coverage gate, one gate over. It would also be read as damage from the reader's own diff.
Not a duplicate
objectui#8369 is the coverage gate's census; this is ESLint's walk. objectui#3549 (closed) is untracked build artefacts from a tsconfig.node.json emit, a different producer and no longer live. Dedup was one targeted search_issues on this repository whose control term returned objectui#8369, objectui#8337 and objectui#7908 — the cards known to be present — so the absence of a card for the lint run is a real read rather than a silent failure.
Shape, not a ruling
The eslint flat config's ignores list (**/dist, **/.next, **/node_modules, **/public, **/.source) is a hand-kept list that a build output only lands in by coincidence. Whether the answer is a row per generated path, an ignores entry derived from git, or nothing at all until the --max-warnings question is decided, is the queue's call and not this card's.
Filed unassigned by the
domain:devxdev seat while implementing objectui#8369. Recording, not claiming — that card's fix is about the coverage GATE's census and deliberately does not touch whateslint .walks.What was measured
objectui#8369 is about
scripts/check-lint-rule-coverage.mjscounting git-ignored build output. Its fix drops those paths from that gate's census. It does not change ESLint's own population, and ESLint still walks them.Measured on
1cca4415eafter a fullturbo run build, one run, both directions in it:The two zeros are what make the 1 a reading rather than a broken invocation: the same invocation in the same run answered both ways.
All three files are build output — git-ignored, absent from
HEAD, created byturbo run build(apps/console/.gitignore:16-17for the twoplugin.*,apps/site/.gitignorefornext-env.d.ts).Why it is worth recording, and why it is not p1
apps/console/plugin.d.tsis emitted bytsc -p tsconfig.plugin.jsonfrom console source. Theanyis in generated output: nobody typed it at that line, and the remedy — if one were ever demanded — is not at the site the report names.Today the consequence is nil, and that is measured too, not assumed:
.github/workflows/lint.ymldeliberately sets no--max-warnings(noted atlint.yml:20and ineslint.config.js's own comment), so a warning fails nothing.⇒ Nothing is red and nobody is blocked. What makes it worth a card is the direction it would fail in if the
--max-warningsthreshold question is ever decided:turbo run lintwould then go red locally, for developers who had built, on a file nobody wrote — the same shape objectui#8369 records for the coverage gate, one gate over. It would also be read as damage from the reader's own diff.Not a duplicate
objectui#8369 is the coverage gate's census; this is ESLint's walk. objectui#3549 (closed) is untracked build artefacts from a
tsconfig.node.jsonemit, a different producer and no longer live. Dedup was one targetedsearch_issueson this repository whose control term returned objectui#8369, objectui#8337 and objectui#7908 — the cards known to be present — so the absence of a card for the lint run is a real read rather than a silent failure.Shape, not a ruling
The eslint flat config's
ignoreslist (**/dist,**/.next,**/node_modules,**/public,**/.source) is a hand-kept list that a build output only lands in by coincidence. Whether the answer is a row per generated path, anignoresentry derived from git, or nothing at all until the--max-warningsquestion is decided, is the queue's call and not this card's.