packages/sdk: eslint cannot run, so nothing lints that package

[feruzm]

Noticed while checking a review finding on #1327 that claimed configured ESLint errors. The finding could not be reproduced because the linter does not run at all.

packages/sdk/package.json declares "lint": "eslint ." and the package has an eslint.config.mjs, but invoking it throws:

Error: Key "rules": Key "@typescript-eslint/no-explicit-any": Could not find "no-explicit-any" in plugin "@typescript-eslint"
    at Object.create (.../@typescript-eslint/utils/dist/eslint-utils/RuleCreator.js:31:20)
    at createRuleListeners (.../eslint@8.57.1/.../linter.js:895:21)

The workspace resolves eslint@8.57.1 while the installed @typescript-eslint build targets eslint 9. The CI lint job is green because it does not cover this package.

Why it matters beyond the one finding

Nothing is checking packages/sdk today, so conventions drift silently and any review comment about lint rules there is unfalsifiable: it cannot be confirmed or refuted by running the tooling. The same is worth checking for the other packages, since a version mismatch of this kind is rarely confined to one of them.

Suggested order

1. Fix the resolution so pnpm --filter @ecency/sdk lint runs. Either move the workspace to eslint 9 or pin @typescript-eslint to a build that supports eslint 8, whichever matches what the other packages expect.
2. See what it reports once it runs. Expect a backlog rather than a clean sheet.
3. Then decide about the as any casts in get-posts-ranked-query-options.spec.ts, which is where this started. There were 15 on develop before refactor(sdk): drop the dead hasNextPage page param and stabilise the display select #1327 and 14 after, so they are the file's existing convention rather than anything that PR introduced. Narrowing them means typing queryFn, getNextPageParamandselectthrough theinfiniteQueryOptions` generics, which is worth doing for the whole file at once.
4. Add the package to whatever CI job is meant to cover it, otherwise this recurs.

Doing 3 before 1 would be tidying a file with nothing to keep it tidy afterwards.

[feruzm]

Correcting this issue: my diagnosis in the description was wrong.

I claimed CI does not cover this package and that nothing lints it. Both are false. pnpm -r lint runs each package's own node_modules/.bin/eslint, which is 9.37.0, and it passes: 555 files, 0 problems. CI has been linting packages/sdk` all along.

What is actually broken is narrower and still worth fixing. A root-resolved invocation gets eslint 8.57.1, because the root package.json declared eslint: "^8" and also declares a workspaces field, so npm walks up to the repo root for its prefix:

$ cd packages/sdk && npx eslint .
ESLint: 8.57.1
TypeError: Error while loading rule '@typescript-eslint/no-unused-expressions': Cannot read properties of undefined

That is the path a developer reaches for, and the path an editor ESLint server rooted at the repo uses. So the linter was unrunnable where people actually run it while CI stayed green through a third route. Three of the four packages fail identically; render-helper survives only because its config never spreads the typescript-eslint recommended set.

Two consequences for what this issue proposed:

• There is no backlog. All four packages report 0 errors and 0 warnings across 706 files. Step 2 of the suggested order has nothing behind it.
• Step 3 is void as written. @typescript-eslint/no-explicit-any is explicitly "off" in packages/sdk/eslint.config.mjs, and linting the file in question exits 0. The as any casts were never going to be flagged even with the linter running, so narrowing them is a typing decision and not a lint fix. My earlier dispute of that review comment was right, but for the wrong reason: I said the linter could not run, when in fact it runs and the rule is disabled.

#1336 fixes the resolution and adds a CI step that lints through the root binary so the skew cannot return silently.