[08/44] Enable TS strict mode in sdk-uve

[nicobytes]

Description

Part of the strict-mode rollout epic #35932. Enable TypeScript strict mode for the sdk-uve project.

• Dependency layer: 1 (0 = leaf library, 10 = top-level app)
• Internal dependents: 7 project(s), 5 of them already strict
• Rollout order: 8 / 44

Approach corrected. The original criteria referenced typescript-strict-plugin, npx tsc-strict, and // @ts-strict-ignore. That approach was dropped — the bootstrap issue #35933 closed without the plugin ever landing. The established pattern is per-project tsconfig.json flags, set by the first merged rollout PR #36879 (dotcms-models). See epic #35932.

This project already satisfies the criteria. See the verification comment below.

Acceptance Criteria

• The six strict flags are present in libs/sdk/uve/tsconfig.json (not tsconfig.base.json, which stays at "strict": false).
• pnpm exec tsc -p libs/sdk/uve/tsconfig.lib.json --noEmit exits 0.
• pnpm exec tsc -p libs/sdk/uve/tsconfig.spec.json --noEmit exits 0.
• No any, @ts-ignore, or @ts-expect-error propping up the result.
• nx run sdk-uve:build / :lint / :test pass.
• The flags are actually enforced by CI — not merely declared.

Priority

Medium

Additional Context

One project in the bottom-up rollout tracked by epic #35932. Full specification: specs/35941-sdk-uve-strict-mode/spec.md.

[nicobytes]

Closing as already satisfied — sdk-uve has met this issue's criteria since February 2025, long before the epic started. No code change was needed.

Evidence

Check	Result
Six strict flags in libs/sdk/uve/tsconfig.json	Present since 277cbbc8f7 ("chore(SDK): Create getUVEState to manage UVE state headlessly", #31242)
tsc -p tsconfig.lib.json --noEmit	0 errors
tsc -p tsconfig.spec.json --noEmit	0 errors
nx run sdk-uve:build / :lint / :test	All pass
: any / <any> / any[] in 4518 lines of source	0
@ts-ignore / @ts-expect-error	0
Non-null assertions (!.)	0

The zero-error result is not propped up by suppressions — the code is genuinely clean.

git log --follow shows libs/sdk/uve/tsconfig.json was created as a 100%-identical copy of libs/sdk/client/tsconfig.json, strict flags included. Same story as sdk-types (#35935): strict from creation, never a later migration.

It is genuinely enforced — three paths, two of them in CI

This is the clause that separated sdk-types (enforced) from dotcms-js (#35939) and utils (#35940), where the flags are declared but nothing verifies them. It was checked at the source rather than inferred.

Path	Type-checks?	Runs in CI?
build (rollup)	Yes	Yes
test (ts-jest)	Yes — diagnostics defaults on, against tsconfig.spec.json	Yes — nx affected -t test, no skip tag
build:js (esbuild)	Yes — compiler: "tsc", skipTypeCheck unset	No — target name doesn't match run-many -t build

rollup.config.cjs sets compiler: 'babel', which is easy to misread as "no type checking". It isn't — compiler governs only the transpile step. @nx/rollup's withNx always inserts a TypeScript plugin (@nx/rollup/src/plugins/with-nx/with-nx.js):

require('rollup-plugin-typescript2')({ check: !options.skipTypeCheck, tsconfig: tsConfigPath, ... })
// or, on the non-legacy branch:
require('@rollup/plugin-typescript')({ ..., noEmitOnError: !options.skipTypeCheck })

sdk-uve sets neither skipTypeCheck nor useLegacyTypescriptPlugin, so the check runs against tsconfig.lib.json — the config carrying the strict flags — and a violation fails the build.

The same mechanism was proven empirically on the sibling sdk-types in PR #36957: reverting a fix there made nx run sdk-types:build fail with @rollup/plugin-typescript TS2564.

That build is unavoidable in CI: project.json has "tags": [] (no skip tags), and the build-test execution in core-web/pom.xml has no <skip> element — -DskipTests=true disables unit-test and -Pvalidate gates lint-test, but neither can turn off the build. @dotcms/uve is also published to npm and matches the sdk-* glob in the SDK release pipeline, so the same type-checked build gates every release. (Note: libs/sdk/uve/package.json says 1.1.1, but that is not what ships — the release action rewrites the version to the dotCMS release tag per ADR-0019 date lockstep. npm latest is 26.8.7-1, across 197 published versions.)

Reproduce

cd core-web
pnpm exec tsc -p libs/sdk/uve/tsconfig.lib.json --noEmit     # 0
pnpm exec tsc -p libs/sdk/uve/tsconfig.spec.json --noEmit    # 0
pnpm exec nx run sdk-uve:build --skip-nx-cache

Adjacent observation (out of scope)

build:js emits dotCMS/src/main/webapp/ext/uve/dot-uve.js, which is committed to the repo, but that target is not invoked by core-web/pom.xml or any workflow. If the source changes and nobody runs it by hand, the committed artifact silently drifts. sdk-client has the same pattern with html/js/editor-js/sdk-editor.js.

Incidental finding (not fixed here)

core-web/tsconfig.base.json:104 maps @dotcms/uve/types → libs/sdk/uve/src/types.ts, a file that does not exist. Nothing imports that specifier and it is absent from the exports / typesVersions maps in libs/sdk/uve/package.json. A dead alias, unrelated to strict mode — worth a separate cleanup ticket.

---

Not linked to PR #36957: there is no diff to attach, and linking it would imply that PR resolved this. It didn't — the project was already compliant.