Lint Code Base: super-linter ignores flat eslint.config.js; BIOME_LINT scans beyond PR diff #306

Summary

While working on #305 (TypeScript SDK), the Lint Code Base super-linter job surfaced two failures that trace back to CI infrastructure gaps rather than problems in that PR's diff. Filing separately so they don't block that PR's review on unrelated ground, and so they're visible for anyone else adding TypeScript under code/.

1. super-linter's TYPESCRIPT_ES check doesn't discover project-level flat eslint.config.js

code/web-client/eslint.config.js and code/sdk/typescript/eslint.config.js both exist as flat ESLint configs and lint clean when run directly:

npx eslint code/sdk/typescript/scripts/generate.ts   # from repo root — passes, 0 errors

But in CI, super-linter/super-linter/slim@v8's bundled TYPESCRIPT_ES linter reports:

/github/workspace/code/sdk/typescript/scripts/generate.ts
  17:24  error  Can't resolve '@apidevtools/json-schema-ref-parser' in '/github/workspace/code/sdk/typescript/scripts'  n/no-missing-import
  18:33  error  Can't resolve 'json-schema-to-zod' in '/github/workspace/code/sdk/typescript/scripts'                   n/no-missing-import

/github/workspace/code/sdk/typescript/test/schemas.test.ts
  1:38  error  Can't resolve 'vitest' in '/github/workspace/code/sdk/typescript/test'  n/no-missing-import

n/no-missing-import isn't a rule enabled by either project's eslint.config.js (both use eslint.configs.recommended + typescript-eslint recommended only, no eslint-plugin-n). This means super-linter is falling back to its own bundled default ESLint config instead of the repo's flat config — most likely because linter.yaml doesn't run npm ci/npm install before linting, and/or super-linter v8's ESLint invocation isn't picking up flat config (eslint.config.js) the way the project intends, resolving node_modules for external packages.

Since code/web-client also only has a flat config and has (as far as I can tell) never had a PR that specifically exercised TYPESCRIPT_ES against it, this may have been latent and unnoticed until now.

Suggested fix directions (not proposing a specific patch — wanted to flag for someone with more context on the linter workflow's intent):

• Point super-linter explicitly at the flat config via TYPESCRIPT_ES_CONFIG_FILE / equivalent flat-config env var for super-linter/slim@v8, or
• Add an npm ci step scoped to changed TS packages before the lint step so node_modules resolves, or
• Confirm whether super-linter/slim@v8 supports ESLint 9 flat config at all in this mode.

2. BIOME_LINT fails against files unrelated to the current diff

With VALIDATE_ALL_CODEBASE: false, I'd expect BIOME_LINT to only check files changed in the PR. Instead it reports "Checked 99 files" and "Found 75 errors" — far more than the ~19 files changed in #305.

I verified this isn't something introduced by #305's changes: e.g. code/sdk/typescript/src/generated/types/jwk.ts's flagged line

.regex(new RegExp("^[A-Za-z0-9_-]{43}$"))

is byte-identical (aside from quote style, itself just a Prettier formatting fix) to what was already committed in #305's first commit — which passed BIOME_LINT cleanly. The second commit (same file content, only a Prettier reformat) triggered the 75-error report. This suggests either:

• Biome's own project-root scan isn't respecting super-linter's changed-files filter and is linting the whole repo (a known category of super-linter + Biome interaction issue), surfacing pre-existing repo-wide findings, or
• Some flakiness/non-determinism between super-linter runs on the same Biome/config version.

Either way, the 75 errors are not something a single incremental PR's diff can reasonably be expected to fix, since most are outside that diff's file set.

Repro

Both failures are visible on #305, specifically the Lint Code Base check on commit f97b0e7. Happy to help debug further if useful, but wanted to raise it separately from the SDK PR since it's an infra question, not a code-correctness one.