[15/44] Enable TS strict mode in data-access

[nicobytes]

Description

Part of the strict-mode rollout epic #35932. Enable TypeScript strict mode for the data-access project.

• Dependency layer: 3 (0 = leaf library, 10 = top-level app)
• Internal dependents: 27 project(s) — the graph reports 27, not the 23 originally stated
• Rollout order: 15 / 44
• Note: Shared services hub - high leverage.

Note: the original acceptance criteria referenced typescript-strict-plugin, npx tsc-strict, and // @ts-strict-ignore. That approach was dropped by the epic — the plugin was never installed. The ACs below reflect the approach actually in force, documented in core-web/CLAUDE.md → TypeScript Strict Mode.

⚠️ The six flags are already present in this project's tsconfig.json — and inert. data-access has no build target, so its own tsconfig is never read, and its 27 dependents compile these sources under their own non-strict configs. 36 lib errors and 47 spec errors sit behind those flags with CI green. The work here is fixing them, not adding flags.

Acceptance Criteria

• The six strict flags are present in data-access's own tsconfig.json (already true — do not re-add):
  forceConsistentCasingInFileNames, strict, noImplicitOverride, noPropertyAccessFromIndexSignature, noImplicitReturns, noFallthroughCasesInSwitch.
• tsc -p libs/data-access/tsconfig.lib.json --noEmit reports 0 errors.
• tsc -p libs/data-access/tsconfig.spec.json --noEmit reports 0 errors.
• All errors resolved with explicit types — no new any. Genuinely nullable declarations are widened rather than silenced.
• @ts-expect-error with a // TODO(#35948): note only where unavoidable; never a blanket @ts-ignore.
• nx run data-access:lint and :test pass, with the test count unchanged.
• Blast radius verified: the 6 already-strict dependents are counted before and after, with zero new errors. Widening public types in this library can only surface errors there.
• Runtime behaviour of the widened services is guarded by the consumer suites (dotcms-ui, ui).
• The enforcement status is recorded — i.e. whether any CI gate actually verifies the strictness.

⚠️ nx run data-access:test does not type-check. tsconfig.spec.json sets isolatedModules: true, which puts ts-jest in transpile-only mode. Passing tests are not evidence of type-cleanliness here; tsc -p is the acceptance test.

Priority

Medium

Additional Context

One project in the bottom-up rollout tracked by epic #35932.

[github-actions]

PRs linked to this issue

• refactor(core-web): TS strict mode across utils-testing, utils, dotcms-js, sdk-create-app, sdk-react, sdk-analytics, sdk-angular, data-access + webcomponents groundwork by @nicobytes

[nicobytes]

Implemented — 83 errors fixed. The flags were already there, doing nothing.

Corrected the stale ACs above first (they described the dropped typescript-strict-plugin approach).

The flags were present and inert

All six flags plus Angular's strictTemplates / strictInjectionParameters / strictInputAccessModifiers had been in libs/data-access/tsconfig.json for some time. Nothing applied them:

• The project has no build target (only lint and test), so its own tsconfig is never consumed.
• Its 27 dependents compile these sources under their own non-strict configs.

So 36 errors sat in a layer-3 shared services hub with CI fully green. This matches the incidental measurement in PR #36957, where data-access dropped 106 → 68 → 36 as dotcms-js and utils were fixed.

Config	Before	After
tsconfig.lib.json	36	0
tsconfig.spec.json	84 (47 own spec + 37 lib pulled in)	0

Neither config had a masking error (TS6053 / TS2688), so both were completing genuine semantic passes. The errors were simply never looked at.

Production source (36)

paginator.service.ts (14) — 8 uninitialised fields given zero values (0 / '') rather than !, which states "empty until the first request" honestly; four parseInt(headers.get(...)) calls take ?? '' (identical NaN outcome); one revealed private setLinks(linksString: string) whose body already handled null (linksString?.split(',') || []) — the signature was simply wrong; and the file-local interface Links gained an index signature because the Link-header parser stores whatever rel the server sends.

_sortOrder was deliberately left optional instead of defaulted. Defaulting it to OrderDirection.ASC would have been a behaviour change: getParams() gates the direction query param on truthiness, and ASC === 1 is truthy where undefined was not — every paginated request in the admin UI would have started sending a param it previously omitted. The public getter widened to OrderDirection | undefined instead.

dot-page-state.service.ts (12) — six declarations widened because they were wrong; the service genuinely emits null:

Site	Was	Now
getInternalNavigationState()	DotPageRenderState	| null — it has an explicit return null
setLock(options, lock)	lock: boolean = null	boolean | null
getLockMode()	Observable<string>	Observable<string | null | undefined>
handleSetPageStateFailed()	Observable<DotHttpErrorHandled>	Observable<undefined>
getFavoritePage()	Observable<DotCMSContentlet>	| undefined
getRunningExperiment()	Observable<DotExperiment>	| null

handleSetPageStateFailed was the instructive one. It ends with map(() => undefined), so it really emits undefined — which means the caller's = [null, null] destructuring default is reachable and load-bearing, not dead code. Declaring the honest type made the whole switchMap typable; it now destructures explicitly (const [page, user] = result ?? [null, null]) instead of fighting an annotation.

One deliberate guard change worth naming: if (page) became if (page && user). forkJoin emits both or the error path yields undefined, so page truthy already implied user present — this makes it explicit rather than asserting non-null.

dot-router (5), dot-localstorage (3), dot-content-types-info (2) — nullable getters (previousUrl is optional on PortletNav; storedRedirectUrl is assigned null by redirectMain), localStorage.getItem reads, and a string index narrowed to keyof.

Specs (47)

25 of them came from three lines. The fake Router declared navigate = jest.fn(() => ...) etc., which infers zero parameters, so every toHaveBeenCalledWith(...) was a TS2554. Typing the three mocks fixed all 25.

Worth knowing for the remaining projects: this file's jest comes from @types/jest, which uses jest.fn<TReturn, TArgs> — two type parameters. @jest/globals (used in sdk-analytics) uses jest.fn<Fn>. Wrong arity gives TS2743.

Two were real bugs hiding behind disabled suites:

• dot-global-message.service.spec.ts imported DotMessageService from dot-alert-confirm.service, which does not export it. The suite is xdescribed, so it never ran.
• dot-ai.service.ts — a production file — did export { DotAiProviderConfig } on a type, invalid under isolatedModules. Only the spec config sets that flag, so only it surfaced the error.

Two more were tests asserting shapes production never uses:

• dot-page-layout.service.spec.ts called save(id, mockDotLayout()), but save takes a DotTemplateDesigner ({ layout, themeId }) and posts it verbatim — which is what the real caller sends (edit-ema-layout.component.ts:111).
• dot-content-drive.service.spec.ts used an offset field removed from DotContentDriveSearchRequest, copied from the model's own stale JSDoc example — fixed here too, so the next person is not misled the same way.

The rest were incomplete fixtures. dot-personas now reuses the existing mockDotPersona from @dotcms/utils-testing rather than hand-rolling 21 fields.

No new any, no @ts-ignore / @ts-expect-error anywhere in the diff.

Blast radius — measured before and after

Widening public types in this library can only introduce errors in already-strict dependents, so all of them were counted. Zero new errors, 218 removed, and three went fully clean — they were carrying nothing but this library's leakage:

Strict dependent	Before	After
global-store	36	0
portlets-dot-analytics-data-access	36	0
portlets-dot-experiments-data-access	36	0
image-editor	148	111
portlets-dot-analytics	151	115
portlets-dot-locales-portlet	147	111
utils-testing	0	0

That is the "high leverage" this issue predicted, quantified.

Runtime guard on the widened services and the paginator initialisers:

Project	Result
dotcms-ui	81 suites, 820 tests pass
ui	221 suites, 2184 tests pass

Results

Gate	Result
tsc -p tsconfig.lib.json --noEmit	36 → 0
tsc -p tsconfig.spec.json --noEmit	84 → 0
nx run data-access:lint	pass
nx run data-access:test	pass — 79 suites, 754 tests, unchanged
nx affected -t build (scoped)	all 6 projects pass

Enforcement: none, by decision

No typecheck target and no CI wiring, consistent with how dotcms-js (#35939) and utils (#35940) were resolved. data-access joins them and sdk-analytics (#35946) as strict, clean, and unverified — nothing will catch a regression of these 83 fixes. That is four projects now; raised on #35932 as one decision rather than four.

A repo-wide finding: test never type-checks specs

jest.config.ts uses jest-preset-angular → ts-jest@29.4.6 against tsconfig.spec.json, which looks like it type-checks. It does not, because that tsconfig sets isolatedModules: true:

• ts-jest/dist/legacy/config/config-set.js:229 — this.isolatedModules = this.parsedTsConfig.options.isolatedModules ?? false
• ts-jest/dist/legacy/compiler/ts-compiler.js:74 — the language-service host is built only if (!this.configSet.isolatedModules)
• _doTypeChecking() needs that host for getSemanticDiagnostics (lines 181, 427)

data-access is the proof: 84 tsc errors alongside 754 passing tests. Since core-web/CLAUDE.md mandates isolatedModules: true in every tsconfig.spec.json, no project's test target type-checks its specs anywhere in this monorepo. "Tests pass" has never been evidence of spec type-cleanliness — including in the reasoning I published on #35947, which is corrected there (that verdict stands; it was measured with tsc -p directly).

Reproduce

cd core-web
export NVM_DIR="$HOME/.nvm" && . "$NVM_DIR/nvm.sh" && nvm use   # 22.22.3
export NX_NO_CLOUD=true

corepack pnpm exec tsc -p libs/data-access/tsconfig.lib.json  --noEmit   # 0
corepack pnpm exec tsc -p libs/data-access/tsconfig.spec.json --noEmit   # 0
corepack pnpm exec nx run data-access:lint
corepack pnpm exec nx run data-access:test --skip-nx-cache
corepack pnpm exec nx run-many -t test -p dotcms-ui ui --skip-nx-cache

pnpm is not on PATH in this worktree — use corepack pnpm.

Note on nx affected -t lint --base=origin/main: six projects fail (dotcms-js, utils, utils-testing, block-editor, dotcms-webcomponents, dotcms-block-editor) for pre-existing, unrelated legacy lint debt, established while working #35946. None of the reported files are in this diff, and all builds pass.

Shipped in PR #36957. Full write-up in specs/35948-data-access-strict-mode/spec.md.

A pattern for the remaining 29: flags present ≠ flags applied. Any project that nx show project reports without a build target may already claim strictness while carrying errors. data-access was the first one measured, and it had 36.