chore: enable strict: true to surface the type-check failures (failing) (#4683)

[eddeee888]

Description

Checkpoint PR for #4683 (Consider using strict: true compiler option). It is intentionally red — it changes no source, it just turns the flag on so the real failure surface is visible in CI instead of estimated.

Related #4683

The whole diff is tsconfig.json: strict: true in, and the four flags the umbrella now subsumes out.

-    "noImplicitThis": true,
-    "alwaysStrict": true,
     "noImplicitReturns": true,
     "noUnusedLocals": true,
@@
-    "noImplicitAny": false,
-    "strictNullChecks": false
+    "strict": true

⚠️ Dropping noImplicitAny: false / strictNullChecks: false is the load-bearing part. An individually-set flag beats the strict umbrella, so adding "strict": true while those two are still present is a no-op — tsc --noEmit --strict reports 0 errors on master today, which is misleading.

noImplicitThis and alwaysStrict are removed as redundant, not as a behaviour change. Verified no-ops from three angles: the same 351 errors byte-for-byte, and identical JS and .d.ts emit across all 214 output files, with and without them.

noImplicitReturns and noUnusedLocals stay — they are not part of the strict family.

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Not breaking as committed (no source change), but see Further comments — the published .d.ts shifts once this is actually adopted.

How Has This Been Tested?

pnpm@11.24.0, typescript@6.0.3, Node 22, Linux.

Command	master	this branch
pnpm types:check	0 errors	351 errors, 50 files, 15 of 19 packages
pnpm build	passes	fails (this is what turns CI red)
pnpm vitest run	passes	passes — vitest transpiles without type-checking
tsc -p tsconfig.spec.json	55 errors (pre-existing)	576 errors

Two things worth flagging about that table:

1. types:check is not wired into any workflow. CI goes red here only because pnpm build runs tsc. Wiring types:check into pr.yml is probably worth doing on its own, but it would widen this PR, so it is not included.
2. tsconfig.spec.json is never checked by pnpm types:check — tsc --noEmit doesn't build project references. Its 55 errors on master are mostly missing test-fixture modules, i.e. it isn't a maintained gate today. The jump to 576 is real but should be scoped separately from the 351.

Where the 351 errors live

Package	Errors
visitor-plugin-common	211
graphql-codegen-cli	32
plugin-helpers	23
typescript	20
fragment-matcher	13
typescript-operations	11
client-preset	10
typed-document-node	9
graphql-modules-preset	7
testing	5
core	4
document-nodes, time, resolvers, add	6 combined

Worst files: base-types-visitor.ts (57), base-resolvers-visitor.ts (47), selection-set-to-object.ts (31), utils.ts (19), client-side-base-visitor.ts (17).

By error code: TS2345 102, TS2322 62, TS18048 40, TS7006 36, TS2783 33, then a long tail.

Which flags actually cost anything

Measured one at a time against master:

Flag	New errors
strictNullChecks	310
noImplicitAny	70
strictPropertyInitialization	1
strictFunctionTypes	0
strictBindCallApply	0
useUnknownInCatchVariables	0

noImplicitThis and alwaysStrict were already on. So three of the eight sub-flags are free — enabling strictFunctionTypes, strictBindCallApply and useUnknownInCatchVariables together produces 0 errors and a byte-identical .d.ts emit. That is a separate, safe, mergeable PR and does not need any of the work below.

Further comments

Two things make the remaining 351 more than a mechanical cleanup:

1. The published .d.ts changes. Emitting declarations both ways and diffing gives 9 changed files, ~50 lines, in visitor-plugin-common, cli, client-preset and testing:

- export declare function mkdirp(filePath: string): Promise<string>;
+ export declare function mkdirp(filePath: string): Promise<string | undefined>;

- checkModeStaleFiles: any[];      - _name: any;    - SchemaDefinition(): any;
+ checkModeStaleFiles: never[];    + _name: null;   + SchemaDefinition(): null;

any → null on a protected field and any[] → never[] break subclasses outright, and visitor-plugin-common is the base-class package community plugins extend. That is the naive diff with the 351 errors unfixed, so it is indicative rather than final — but the shape is a type-level breaking change for downstream plugin authors.

2. Some fixes are behaviour decisions, not annotations. The 33 TS2783s are all super({ ...defaults, ...additionalConfig }) in base-resolvers-visitor.ts:758-795, where the spread order deliberately lets plugin config win; "fixing" it means retyping additionalConfig as partial or reordering, and reordering changes behaviour. Likewise each of the 40 TS18048 "possibly undefined" sites on a config read forces a choice of default — and those defaults decide generated output, guarded only by snapshot tests.

Suggested sequencing: (a) land the three free flags, (b) decide a progressive mechanism — there is one root tsconfig.json covering all of packages, so there is nowhere for per-package opt-in to land today, (c) batch strictNullChecks/noImplicitAny into a major with a migration note.

Checklist

• I have performed a self-review of my own code
• I have added tests that prove my fix is effective — n/a, this PR proves a failure, it doesn't fix one
• My changes generate no new warnings — it generates 351 errors, deliberately
• New and existing unit tests pass locally with my changes (vitest is green; tsc is not)
• I have made corresponding changes to the documentation — n/a until a direction is picked

No changeset: nothing here is publishable.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01HcWBL7VGPvQGV2Rbc8fXVm

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7cc512a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR