Skip to content

finding(devx): option 1 on objectui#8337 -- widening the rule-bearing globs to .mts/.cts has an EMPTY red set, measured #8469

Description

@baozhoutao

Split out of objectui#8337, whose triage routed that card to option 2 (gate the gap) and held option 1 back with one specific objection:

Option 1 (widen the glob) requires measuring the red set first, and must not be taken as "one line, obviously right" ... the red set is UNMEASURED, and turning rules on for a config file nothing has ever linted is a rule-STRENGTH decision, not a coverage fix.

The objection was about a missing number. This card carries the number. It does not propose taking option 1 — that is still a rule-strength decision and it has an owner.

The measurement

Taken on 868e825012 (objectui#8337's implementation base), real install, ESLint v10.8.1, while implementing option 2. The mutation proved it landed on disk by marker count (2 before, 2 after) and by hash differing from the HEAD blob before any result was read, ran under a trap with absolute paths, and the restore was proven by state (git diff HEAD empty), not by an exit code.

Mutation: add mts,cts to both rule-bearing files globs in eslint.config.js, i.e. the two occurrences of the TS-and-TSX brace expansion become a TS-and-TSX-and-mts-and-cts one.

vitest.config.mts                   ->  isPathIgnored: false, 116 rules
pnpm exec eslint vitest.config.mts  ->  EXIT=0, no output at all

Zero errors, zero warnings. The red set is empty. The only .mts file in the repository passes all 116 rules today, and there are no .cts files for it to surprise.

What this does and does not settle

  • ✅ It removes the objection that blocked option 1, which was specifically that the red set was unknown.
  • ⛔ It does not make option 1 free. Turning rules on for a population that has never been linted is a strength change, the same class the objectui#7908 dispatch kept out of scope for the .js family, and it stays with whoever owns strength decisions here.
  • ⚠️ It is a reading of today's tree. A .cts or a second .mts landing later can move it, and the empty red set is not a standing property.
  • ⭐ The population is wider than the two extensions this card names. Measured in the same run by deriving the unreachable set from the live config rather than listing it: .jsx is unreachable too, for exactly the same reason, and neither objectui#8337 nor its triage names it. There are no .jsx files today, so nothing reported it and nothing would have. Any widening should decide about all three, not two.

Relationship to the gate

PR #8467 landed objectui#8337's option 2, so the gap is now reported rather than silent, and vitest.config.mts is a declared row in that gate's second ledger. If option 1 is ever taken, that ledger row goes red in both shrink-only directions and the failure text names the remedy (delete the row) — verified as an ablation leg on that PR. So this card and that gate do not conflict: taking option 1 is a mechanically guided single-row deletion, not a second edit somebody has to remember.

Observation-class, unassigned, not claimed. Filed by an agent dev seat while implementing objectui#8337; the session reference is session_01FhBNJcLRZLe8M87VcUgpKr, and this attribution is written as prose deliberately.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:devxobjectui devx stream: fix lands on .github/, scripts/ or release pipeline — devx lane cross-repofindingpm:queuepriority:p3tooling

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions