[21/44] Enable TS strict mode in portlets-dot-analytics-data-access

[nicobytes]

Description

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

• Dependency layer: 3 · Internal dependents: 1 · Rollout order: 21 / 44

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 in force, documented in core-web/CLAUDE.md → TypeScript Strict Mode.

Acceptance Criteria

• The six strict flags are present in the project's own tsconfig.json:
  forceConsistentCasingInFileNames, strict, noImplicitOverride, noPropertyAccessFromIndexSignature, noImplicitReturns, noFallthroughCasesInSwitch.
• tsc -p <projectRoot>/tsconfig.lib.json --noEmit reports 0 errors.
• tsc -p <projectRoot>/tsconfig.spec.json --noEmit reports 0 errors.
• All errors resolved with explicit types — no new any.
• nx run <project>:lint and :test pass.
• nx affected -t build,lint does not break dependents.
• The enforcement status is recorded — i.e. whether any CI gate actually verifies the strictness.

⚠️ Two things that make error counts untrustworthy here, both established earlier in this rollout:

• :test does not type-check. isolatedModules: true puts ts-jest in transpile-only mode ([15/44] Enable TS strict mode in data-access #35948), so passing tests say nothing about types. tsc -p is the acceptance test.
• A files entry pointing at a missing file (TS6053, [14/44] Enable TS strict mode in sdk-angular #35947) or an uninstalled types entry (TS2688, [11/44] Enable TS strict mode in utils-testing #35944) aborts tsc before semantic checking. Confirm the compiler reached the code.

Priority

Medium

Additional Context

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

[nicobytes]

Verified — compliant. Its one error belonged to global-store.

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

All six flags were already present in this project's own tsconfig.json, and it was not masked by a TS6053 / TS2688 config error.

Config	Before	After
tsconfig.lib.json	0	0
tsconfig.spec.json	1	0

The one error was not this project's

tsc -p tsconfig.spec.json reported exactly one error, and the path pointed elsewhere:

libs/global-store/src/index.ts(3,10): error TS1205: Re-exporting a type when
'isolatedModules' is enabled requires using 'export type'.

global-store's barrel did export { WebSocketStatus } on what is actually a type. Its own configs never reported it — no spec there imports ./index, so the file was never in its own program. It only becomes visible from a consumer that pulls the barrel in under a config with isolatedModules: true, which is this one.

Fixed in global-store as part of #35951, taking this project to 0 with no edit here.

Worth carrying forward: an error attributed to your project may live in a dependency's barrel file. Read the path before assuming ownership.

Results

Gate	Result
tsc -p tsconfig.lib.json --noEmit	0
tsc -p tsconfig.spec.json --noEmit	1 → 0
nx run portlets-dot-analytics-data-access:lint	pass
nx run portlets-dot-analytics-data-access:test	pass — 217 tests

Not enforced

No build target — only lint and test, and :test does not type-check (isolatedModules: true ⇒ ts-jest transpile-only, per #35948). Same category as #35939 / #35940 / #35946 / #35948; raised on #35932.

Shipped in PR #36957. Write-up in specs/35954-portlets-dot-analytics-data-access-strict-mode/spec.md.

[github-actions]

PRs linked to this issue

• refactor(core-web): TS strict mode across 21 projects — utils, dotcms-js, sdk-*, data-access, ui, portlets, dotcdn by @nicobytes