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.
Summary
While working on #305 (TypeScript SDK), the
Lint Code Basesuper-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 undercode/.1.
super-linter's TYPESCRIPT_ES check doesn't discover project-level flateslint.config.jscode/web-client/eslint.config.jsandcode/sdk/typescript/eslint.config.jsboth exist as flat ESLint configs and lint clean when run directly:npx eslint code/sdk/typescript/scripts/generate.ts # from repo root — passes, 0 errorsBut in CI,
super-linter/super-linter/slim@v8's bundled TYPESCRIPT_ES linter reports:n/no-missing-importisn't a rule enabled by either project'seslint.config.js(both useeslint.configs.recommended+typescript-eslintrecommended only, noeslint-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 becauselinter.yamldoesn't runnpm ci/npm installbefore linting, and/or super-linter v8's ESLint invocation isn't picking up flat config (eslint.config.js) the way the project intends, resolvingnode_modulesfor external packages.Since
code/web-clientalso only has a flat config and has (as far as I can tell) never had a PR that specifically exercisedTYPESCRIPT_ESagainst 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):
TYPESCRIPT_ES_CONFIG_FILE/ equivalent flat-config env var forsuper-linter/slim@v8, ornpm cistep scoped to changed TS packages before the lint step sonode_modulesresolves, orsuper-linter/slim@v8supports ESLint 9 flat config at all in this mode.2.
BIOME_LINTfails against files unrelated to the current diffWith
VALIDATE_ALL_CODEBASE: false, I'd expectBIOME_LINTto 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 lineis 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_LINTcleanly. The second commit (same file content, only a Prettier reformat) triggered the 75-error report. This suggests either: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 Basecheck 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.