chore(lint): delete the two stale eslint-disable directives (the measurement #4853's ruling requires) - #7909
Merged
baozhoutao merged 2 commits intoSep 6, 2026
Conversation
Both name a rule that is not configured for the file they sit in, so each
suppresses nothing and ESLint already reports them (its flat-config default
for `linterOptions.reportUnusedDisableDirectives` is `warn`, and
`.github/workflows/lint.yml` sets no `--max-warnings`, so the report is inert
today).
- apps/console/src/__tests__/bootSplash.test.ts: `no-new-func` is not in
`js.configs.recommended` and nothing else enables it, so it is absent from
the 117 rules `eslint --print-config` resolves for that file.
- scripts/github-slug.mjs: `eslint.config.js` scopes every rule-bearing config
object to `**/*.{ts,tsx}`, so `--print-config` resolves 0 rules for a `.mjs`
file and none of the three named rules was ever enabled there. The vendored
regex beneath is untouched.
Code under both directives is unchanged; only the directive lines go.
Part of #4853 — the measurement that card's ruling requires before the
`reportUnusedDisableDirectives: 'error'` flip. The flip itself is not in this
PR: the ruling requires a measured zero first, and this is the PR that
produces it.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013uAaxiwgYDybsTNV9xwa1M
…thing Comment-only deletions; empty frontmatter is the explicit exemption `scripts/check-changeset-presence.mjs` documents. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013uAaxiwgYDybsTNV9xwa1M
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
baozhoutao
marked this pull request as ready for review
September 6, 2026 02:51
This was referenced Sep 6, 2026
baozhoutao
deleted the
claude/issue-4853-report-unused-disable-directives
branch
September 6, 2026 03:19
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
2 participants
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.
Part of #4853 — the measurement its maintainer ruling requires before the gate flip, and the cleanup that ruling's own fallback branch mandates. ⛔ The flip is not in this PR, and #4853 stays open for it.
The ruling this executes
Comment
5536044589(maintainer, 2026-09-04, batch #28) delegates timing to the devx seat under a condition it measures: the dev runs a real install and lint in a worktree first, and the flip proceeds only if the stale-directive count is 0 — "if not, a separate cleanup PR lands first and the flip waits."⇒ The count is 2. So this is that separate cleanup PR.
The measurement
Branch point
fa7d66c4(origin/mainat claim time), realpnpm install --frozen-lockfile, ESLint v10.8.1.How the population was mirrored. CI's lint step is exactly
pnpm lint=turbo run lint, whose task graph is 46 per-packagelintscripts plus//#lint:root(turbo'slinttask declaresdependsOn: ["//#lint:root"], so the root script is insidepnpm lint, not beside it) — 47 tasks, confirmed byturbo run lint --dry=jsonand by the real run's ownTasks: 47 successful, 47 total. Rather than rely on turbo forwarding passthrough args into a root task, each of those 47 commands was executed directly from its own task directory with the CLI severity flag appended, so no config file was touched to take the reading:No package ships its own
eslintbinary — all 47 resolve the same hoistednode_modules/.bin/eslintv10.8.1 — andlint.ymlis the only workflow in the repo that runs ESLint, so this is the whole population and nothing double-counts.Result — 2 stale directives, both reported at
errorunder the flag:apps/console/src/__tests__/bootSplash.test.ts:169:5eslint-disable-next-lineno-new-funcno-new-funcis not injs.configs.recommendedand nothing else enables itscripts/github-slug.mjs:44:1eslint-disable(block, rest of file)no-control-regex,no-misleading-character-class,no-useless-escape.mjspathPer-rule reconciliation (the #4849 shape):
no-new-funcno-control-regex.mjsno-misleading-character-class.mjsno-useless-escape.mjseslint --print-configis the evidence, not inference:scripts/github-slug.mjsresolves 0 rules (every rule-bearing object ineslint.config.jsis scopedfiles: ['**/*.{ts,tsx}']or narrower).apps/console/src/__tests__/bootSplash.test.tsresolves 117 rules, andno-new-funcis not among them.vitest.config.tsresolves 116.⇒ Deleting either changes lint's verdict on live code by nothing, which is the "mechanical deletion" test. The vendored regex under the second directive is byte-untouched; it is not covered by
scripts/upstream-port-pin.json(that pin lists onlyscripts/pm/check-half-states.mjs), andscripts/__tests__/check-doc-links.test.ts, which pins that regex against the realgithub-slugger, passes.Before and after, same command, same population:
fa7d66c4)⭐ The warning count and the file-row count are identical across the two runs. That is the evidence that this diff removed the two findings and nothing else.
Reverse verification — the instrument can go red, and by name
Deleting things until a count reaches zero proves nothing unless the counter can still fail. Planted a directive that cannot possibly be used (
no-debugger, above anew Function(...)call), proved it reached disk, ran the same flagged command, then restored:The delta between the two legs is exactly one error, at the planted line, naming the planted rule. The restore leg used
git checkout HEAD -- PATH(never the bare form, which would take the mutation back out of the index) under atrap ... EXIT INT TERMwith absolute paths.Gates, at the final head
1d99f8140pnpm lint(turbo,--concurrency=2)Tasks: 47 successful, 47 totalpnpm lint:root32 problems (0 errors, 32 warnings)pnpm lint:coveragelint coverage: 46/46 packages linted, 0 with outstanding errors (0 total).pnpm check:control-bytescheck-control-bytes: OK (scanned 6397 tracked text file(s); skipped 85 binary).node scripts/check-changeset-presence.mjs1 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)pnpm changeset:checkAll workspace packages are in the changeset fixed group.vitest runon the two affected test filesTest Files 2 passed (2)·Tests 136 passed (136)pnpm lint: 46 of the 47 tasks were served from turbo's cache, keyed on inputs the last commit did not move (it adds one.changeset/*.md);//#lint:rootwas the one uncached task. The full uncached 47-task run is the one quoted above atTasks: 47 successful, 47 total·Cached: 0 cached, 47 total.The changeset has an empty frontmatter: the deletions are comment-only, so this releases nothing, which the presence gate names as an explicit pass rather than a workaround.
What is deliberately NOT here
eslint.config.jsis untouched —linterOptionsandreportUnusedDisableDirectivesstill have zero occurrences in it. finding: 失效 eslint-disable 已清零(#4833/PR4849),linterOptions.reportUnusedDisableDirectives: 'error'一次关门的前置已备 —— 门禁强度变更待裁 #4853 stays open, and its remaining step is a second dispatch that re-measures (the count can go non-zero again at any merge) and then adds the one block.--max-warnings. Ruled out by the maintainer and by the standing policy at.github/workflows/lint.yml:20; ⛔ that file is untouched.Two things the next seat should carry into the flip
warnand has been all along. ESLint v10's own default isreportUnusedDisableDirectives: 1, innode_modules/eslint/lib/config/default-config.js, andeslint --print-configon any file in this repo confirmslinterOptions: {reportUnusedDisableDirectives: 1}today. Both of these directives were therefore already being reported on every CI run and were inert only becauselint.ymlsets no--max-warnings. The flip is1to2on an option that is already on, not the introduction of a new check.errorregardless of anyone's diff. That is what makes the re-measure immediately before the flip load-bearing rather than ceremonial.eslint.config.js's three site comments at:57,:117and:294stay true either way — they are about rule severity under a missing--max-warnings, and this option is neither.Out of scope, filed separately
#7908 —
eslint.config.jsresolves zero rules for every.js/.mjs/.cjspath, so 89 of the 252 fileslint:rootwalks (35%, including all ofscripts/*.mjs) are linted against nothing while the command exits 0. Found by this measurement, via the second directive above. Unassigned, ⛔ not addressed in this PR.Maintainer note
Not a governed surface (
apps/console/src/**,scripts/*.mjs,.changeset/**), so no human-merge hold applies from that rule. Kept DRAFT anyway and auto-merge deliberately ⛔ not enabled: the PM seat owns the merge-queue timing for everything on this card per ruling 2(b), and this seat does not pick that window.Generated by Claude Code