TypeScript 6 is blocked: typescript-eslint misreads types under it

[spaceninja]

This repo is on TypeScript 5.9.3 and never got the v6 upgrade. It will need it before the ESLint 10 / @cloudfour/eslint-config v26 work in #2458 can land.

Why we're stuck on 5.x

Renovate opened #2437 (TypeScript v7), which was closed because TypeScript 7 is incompatible with typescript-eslint — it peers typescript: ">=4.8.4 <6.1.0". Unlike our sibling repos there was never a v6 PR here at all, so nothing replaced it.

@cloudfour/eslint-config did make the jump — cloudfour/eslint-config#704 merged TypeScript v6 there.

Why it matters

@cloudfour/eslint-config v26 is built on eslint-config-xo@1.0.0, which declares:

peerDependencies: { typescript: ">=6" }

On TypeScript 5.9.3 that peer is unsatisfied, so npm installs typescript@7.0.2 alongside our pinned copy to satisfy it, dragging in TypeScript 7's @typescript/typescript-* platform binaries. Those aren't in package-lock.json, so npm ci fails with Missing: typescript@7.0.2 from lock file. That is exactly what's breaking cloudfour/simple-svg-placeholder#302 right now.

Why 6.0.3 specifically

The two peer ranges in play only overlap on the 6.0.x line:

Package	Peer range
eslint-config-xo@1.0.0	typescript: ">=6"
typescript-eslint@8.66.0 (a dependency of xo)	typescript: ">=4.8.4 <6.1.0"

TypeScript 7.0.2 is currently latest on npm but fails the second range — which is why #2437 was closed. 5.9.3 fails the first. 6.0.3 is the only line satisfying both.

Two separate blockers here

Worth being explicit that this repo has two independent things standing between it and v26, and fixing one won't unblock #2458 on its own:

1. This issue — TypeScript 5.9.3 vs xo's >=6 peer.
2. Drop eslint-plugin-react so we can upgrade to ESLint 10 #2464 — eslint-plugin-react@7.37.5 supports ESLint ^9.7 at most, so it can't coexist with v26's eslint ^10.6.0 requirement.

#2458 currently fails at npm ci on the second of those, so the TypeScript problem hasn't even surfaced there yet. It will once #2464 is resolved.

This one needs a real check

This repo uses TypeScript properly — there's a tsconfig.json and a ts-dist build output — so 5.9.3 → 6.0.3 is a genuine major upgrade, not the peer-satisfying formality it is in simple-svg-placeholder. It should get a full type-check and build, with a review of anything TypeScript 6 newly rejects.

[spaceninja]

I tried this and hit something that says we should hold off. TypeScript 6.0.3 itself is fine here — it is the type-aware lint rules that break, in a way whose autofix would delete correct code.

What the upgrade does

Bumping typescript 5.9.3 → 6.0.3 and reinstalling:

• npm run type (tsc) — passes, no errors
• npm run build — passes
• npm test — 25 passed
• npm run lint:check — 38 errors, where main has none

37 of the 38 are @typescript-eslint/no-unnecessary-condition. They are false.

The reports are wrong

From src/components/input/elastic-textarea.ts:

const minRows = Number(textarea.getAttribute('rows')) || 2;   // "always falsy"
const isScrolling = () => textarea.scrollHeight > textarea.clientHeight;
while (isScrolling()) {                                        // "always falsy"

A comparison of two numbers cannot be statically always-false. tsc itself, on the same code and the same TypeScript, reports nothing.

That matters more than the noise, because no-unnecessary-condition is autofixable. Running npm run lint:js would strip the || 2 fallbacks, the loop guards and the optional chaining that these rules claim are redundant — silently turning working code into broken code.

Isolated reproduction

The whole thing reduces to this file, with the repo's own config:

export const probe = (element: HTMLTextAreaElement) => {
  const rows = Number(element.getAttribute('rows')) || 2;
  const scrolling = element.scrollHeight > element.clientHeight;
  if (scrolling) {
    return rows + 1;
  }

  return rows;
};

TypeScript	Result
6.0.3	2 × no-unnecessary-condition, "value is always falsy"
5.9.3	clean

Nothing else changed between those runs — same ESLint, same config, same rules, same file.

I also checked whether it was a lib resolution problem, since TS 6 widens what target: esnext pulls in and there are upstream reports of Invalid value for lib provided: es2025.iterator. Pinning "lib": ["ESNext", "DOM", "DOM.Iterable"] explicitly made no difference, so that is not it.

Where the fault is

@typescript-eslint/typescript-estree@8.67.0 declares typescript: ">=4.8.4 <6.1.0", so 6.0.3 is inside its supported range — it just does not appear to read types correctly there. Upstream's TypeScript 6 Support issue is closed as completed, and it does flag that TS 6.0 "reduces context-sensitivity for functions that don't reference this", which "may change type inference results in some edge cases". That is the right neighbourhood, but a numeric comparison being always-false is not an edge case, it is broken.

I have not tested typescript-eslint@8.69.0 (current latest). Its peer range is identical, so I would not assume it differs, but it is the first thing to check when we retry.

Suggestion

Hold this issue rather than close it. Nothing here is urgent on its own — we are only on this path because eslint-config-xo peers typescript: ">=6".

Worth noting for #2458: with #2466 merged, the eslint-plugin-react blocker is gone, so the next step is to try ESLint 10 and config v26 while staying on TypeScript 5.9.3 and see whether it installs. xo's typescript peer is optional, so it may resolve fine. If npm instead auto-installs a typescript@7 to satisfy that floor — which is exactly what broke cloudfour/simple-svg-placeholder#302 — then we are stuck between a lint stack that needs <6.1.0 and a config that wants >=6, and that is worth raising with the config rather than working around here.