type-check-baselines

name: type-check-baselines description: >- Run, refresh, or recover from RedisInsight's per-project TypeScript error baselines (.tscheck.rec.json). Use when CI reports "baseline is outdated" or "more TS errors than previously recorded", when the user mentions tscheck / type-check / .tscheck.rec.json, when introducing or fixing TS errors, or when reviewing PRs that touch baseline files.

TS error baselines

RedisInsight gates TypeScript errors per project via a one-way ratchet: current error counts are recorded in .tscheck.rec.json files, and CI fails if any (file × error-code) count increases. Counts can only go down.

Projects and commands

Run all checks together from the repo root:

• yarn type-check — compare against baselines (all four projects). E2E Playwright is type-checked by a separate workflow (tests-e2e-playwright-lint.yml) — not part of this.
• yarn tscheck — refresh baselines for ui/api/desktop after fixing errors. Projects whose error count didn't change produce no diff.
• yarn tscheck:force — force-overwrite baselines for ui/api/desktop. Emergencies only.

Always run refresh commands through the root yarn tscheck / yarn tscheck:force wrappers. The per-workspace refresh scripts (yarn --cwd redisinsight/<ws> tscheck) shell out to tsc, tsx, and tsc-output-parser, which are installed only in the root node_modules/.bin/ — this repo is not a yarn workspace, so yarn won't add the root bin dir to PATH when invoked with --cwd. The root wrappers exist precisely to avoid that trap by running in the root yarn context first. If you must invoke the per-package script directly, prepend the root bin dir manually: PATH="$PWD/node_modules/.bin:$PATH" yarn --cwd redisinsight/ui tscheck.

API has a dedicated check tsconfig

redisinsight/api/tsconfig.check.json extends the base tsconfig.json and adds:

"strict": true,
"strictPropertyInitialization": false,
"useUnknownInCatchVariables": false,
"noEmit": true

The base tsconfig.json stays as-is so nest build is unaffected. Never enable strict in the base — it breaks the production build.

Workflows

CI says "more TS errors than previously recorded"

You introduced new errors. Fix them. Read the script output — it lists the file, error code (TSxxxx), and message for each new error. Do not run tscheck:force in any workspace to paper over them.

CI says "baseline is outdated"

You fixed errors (good). Refresh baselines from the repo root:

yarn tscheck

This runs the refresh for ui, api, and desktop; only the project whose count changed will produce a diff. Commit the updated .tscheck.rec.json.

Adding a brand-new file with TS errors

Same rule: the file × error-code counts went from 0 to N — that's "new errors". Fix them before merging. Strict-mode escape hatches (as any, // @ts-expect-error with justification) are acceptable when fixing legitimately is out of scope, but prefer real fixes.

Bootstrapping a fresh baseline

Only needed once per project (already done for ui/api/desktop). The non-force yarn --cwd redisinsight/<workspace> tscheck calls compare first, which fails against an empty baseline. Use yarn --cwd redisinsight/<workspace> tscheck:force for the very first baseline only.

After yarn install in redisinsight/api/

The api postinstall regenerates redisinsight/api-client/. That can shift UI and Desktop error counts (they both import from apiClient). If yarn type-check:ui or yarn type-check:desktop reports drift after an api install, refresh those baselines.

Local UI check disagrees with CI

UI plugins under redisinsight/ui/src/packages/{redisearch, redisgraph, redistimeseries-app, ri-explain, clients-list} are sub-projects whose source gets type-checked via the UI tsconfig. Their deps live in nested node_modules populated by yarn build:statics (or by running yarn --cwd redisinsight/ui/src/packages/<plugin>). CI runs yarn build:statics before yarn type-check:ui, so the baseline reflects "plugin deps installed."

If yarn type-check:ui shows TS7016 ("Could not find a declaration file for module ...") errors that CI doesn't, you're missing plugin deps. Run yarn build:statics once, then re-run the check. Don't refresh the baseline to your local state — CI runs with plugin deps installed.

Local Desktop check disagrees with CI

Desktop type-check needs redisinsight/api/dist/ populated with the dev nest build (yarn --cwd redisinsight/api build, not build:prod — prod skips .d.ts emission). CI does this automatically. Locally, build api once before generating or refreshing the desktop baseline.

Reviewing PRs

Reject PRs that:

• Bump a .tscheck.rec.json file × code count up without a corresponding code fix.
• Use tscheck:force in any workspace (look for the diff: a force overwrite typically touches many lines in the rec file with no related TS changes).
• Enable strict in redisinsight/api/tsconfig.json (the base). Strict for api belongs only in tsconfig.check.json.

Approve PRs that:

• Leave counts unchanged.
• Decrease counts (with the rec file updated and committed).