refactor(core-web): TS strict mode across 30 projects — template-builder, edit-ema-ui, block-editor, ui, data-access, sdk-*, portlets

[nicobytes]

What

Thirty-three steps of the strict-mode rollout (epic #35932), plus groundwork on one more (dotcms-webcomponents, not closed):

Issue	Project	Change
#35974	edit-content	101 + 208 errors. The spec config had opt-outs hiding 666 of them. Most fixes were declarations lagging behind bodies already written for null
#35976	dotcms-binary-field-builder	Had none of the six flags. Its own tsconfig compiles nothing (include: []), so measuring that file reported a fake zero
#35967	portlets-dot-query-tool-portlet	Two flags missing. Its noImplicitReturns-without-strict combination caught a TS7030 I introduced in edit-content
#35971	edit-ema-ui	119 errors. Two stores declared their pre-render state non-nullable; a spec caught me changing a wire payload
#35958	template-builder	141 errors, plus 27 that came from a fixtures file being compiled as production code
#35973	dotcms-block-editor	Three tsconfigs had never type-checked anything (TS2688). Unmasking them surfaced a template defect that only a build can see
#35955	block-editor	442 own errors. Four wrong declarations explained most of them, including an Omit that silently erased every member of PrimeNG's MenuItem
#35970	dotcdn	19 errors, 8 of them from one missing switch default. First app to go strict — surfaced template errors in libs/ui
#35969	portlets-dot-usage	One fixture field, plus a global fix for the htmldiff-js type leak
#35968	portlets-dot-tags-portlet	18 of 22 were Signal↔jest.Mock casts; one catch binding
#35965	portlets-dot-locales-portlet	Flags were present but unsatisfied — two wrong DynamicDialogRef annotations, of(null) for Observable<void>
#35963	portlets-dot-es-search-portlet	All 28 spec errors were jest.fn() assigned onto signal-typed members
#35962	portlets-dot-categories-portlet	Fixture drift in two directions plus the signal-mock pattern
#35960	edit-content-bridge	Dialog ref captured in a local; a control-flow blind spot in its spec
#35954	portlets-dot-analytics-data-access	Compliant — its one error lived in global-store's barrel
#35952	portlets-dot-experiments-data-access	Already compliant, no diff
#35951	global-store	One-line export type that also closed #35954
#35950	portlets-dot-locales-data-access	Already compliant, no diff
#35949	sdk-experiments	Flags-only; enforcement proved by negative test
#35966	portlets-dot-plugins-portlet	Reported 733, had 63 — moduleResolution: node10 broke 256 imports. Also corrects the portlets guide that recommended it
#35961	portlets-dot-analytics	Spectator's typed props vs Angular's input aliases; two more type-only barrels; @types/d3-* added
#35959	content-drive-ui	A drop with no active node emitted a payload its own type forbids
#35956	new-block-editor	38 of 60 were TS4111 on TipTap attrs; EditorView sourced from @tiptap/pm/view; @types/turndown added
#35953	ui	549 → 0. The rollout's bottleneck: ~109 errors leaked into each of its 26 dependents
#35948	data-access	Flags were present but inert (no build target) — fixes the 36 lib + 47 spec errors hiding behind them
#35947	sdk-angular	Already compliant — removes dead next/ tsconfig refs that made tsconfig.spec.json unverifiable (TS6053)
#35946	sdk-analytics	Enable the 5 missing flags + fix 18 TS4111 in source and 29 in specs (14 pre-existing)
#35945	sdk-react	Enable the 5 missing flags + fix 14 TS4111 index-signature accesses
#35944	utils-testing	Strict was declared but inert — a stale types: ["jasmine"] aborted all type checking
#35940	utils	Enable strict + fix the 32 (+17 spec) resulting type errors
#35939	dotcms-js	Enable strict + fix the 38 resulting type errors
#35938	sdk-create-app	Enable strict + fix the 2 resulting type errors
#35935	sdk-types	No code needed — it was already strict. Documents the rollout pattern instead.

All three add the standard six flags to the project's own tsconfig.json, following the pattern established in #36879 (dotcms-models). tsconfig.base.json stays at "strict": false — the rollout never flips it globally.

---

dotcms-js (#35939)

The largest of the three: 38 errors across 11 files, in a layer-1 core library with 20 dependent projects, including the dotcms-ui admin app. Six of those dependents are already strict, so this library's loose types were leaking uncertainty into projects that had opted into rigour.

Most fixes correct types that were simply wrong, rather than silencing the compiler:

Site	Was	Reality
Auth.loginAsUser	User	The code has always passed null when nobody is impersonating, and every consumer already guards with auth.loginAsUser || auth.user. Now User | null.
StringUtils.getLine	string	Its own JSDoc says "null if it does not exists". Now string | null.
HttpRequestUtils.getQueryStringParam	string	Same — JSDoc already documented the null case.
RoutingService.getPortletURL	string	Returns Map.get(). Now string | undefined.
SiteService.switchSiteById	Observable<Site>	Emits of(null) when no site is found. Now Observable<Site | null>; its one consumer already handled null.
ResponseView.bodyJsonObject	DotCMSResponse<T>	Assigned from HttpResponse.body, which is nullable. The surrounding try/catch could never throw and has been removed.

LoginService.urls moved from Record<string, string> to inference-typed, which resolves all 8 TS4111 errors at once and gives each endpoint a named property.

Two definite-assignment assertions were used, each with a TODO: LoginService._auth and SiteService.selectedSite are assigned during init but not in the constructor. Modelling them as | undefined is the truthful type, but their public getters (auth, currentSite) are consumed by already-strict projects, so widening them is a public-API change that belongs in its own issue.

No new any, @ts-ignore, or @ts-expect-error anywhere in this PR.

⚠️ dotcms-js has no build target and is tag-excluded from lint and test, so nothing in CI verifies these flags. They document intent; they do not enforce it. This was an explicit scoping decision — no typecheck target or CI gate was added. The six already-strict consumers provide partial, incidental coverage only. Full reasoning in specs/35939-dotcms-js-strict-mode/spec.md, which is included in this PR.

Blast-radius verification

data-access (a strict consumer) went from 106 type errors to 68, with zero new errors introduced — the honest types upstream remove noise downstream. dotcms-ui typechecks clean apart from a pre-existing missing dotcms-webcomponents/loader dist.

---

utils (#35940)

32 errors across only 3 files, plus 17 more that appeared in the spec files once the flags propagated through tsconfig.spec.json (baseline there was 0). Both are fixed here — leaving the spec errors would have shipped a regression.

The bulk was one constant. EMPTY_FIELD assigned null to 18 members that DotCMSContentTypeField declares non-nullable:

• Replaced with zero values of the declared types. Verified safe: nothing compares those members to null strictly — consumers use falsy checks such as isNewField's !field.id — so '', 0 and false behave identically at runtime.
• clazz has no zero value (DotCMSClazz is a union of concrete Java class names), so EMPTY_FIELD and EMPTY_SYSTEM_FIELD are now Omit<DotCMSContentTypeField, 'clazz'>. They are partial templates, not valid fields, and the type now says so. The derived COLUMN_FIELD / ROW_FIELD / TAB_FIELD already supply their own clazz, so they remain complete.

Other fixes:

Site	Change
getFieldsWithoutLayout	Truthy .filter() did not narrow the optional row.columns. A type predicate clears the TS2532 and both TS2769 without a cast.
ellipsizeText	Accepted null/undefined at runtime — its own guard and its tests say so — but declared string/number. Widened to match, with an explicit limit == null check so later comparisons narrow.
fallbackErrorMessages	Typed { [key: number]: string }, mirroring the identical declaration already in libs/data-access/.../dot-upload.service.ts.
dot-utils.ts	Bracket access for the six DotCMSContentlet index-signature reads in getImageAssetUrl.
dot-asset.service.ts	Explicit types for promises and the two fetchAsset params.

The nine as unknown as casts added are all in spec files, on inputs the tests deliberately pass as invalid, matching the idiom those files already used.

⚠️ Same enforcement gap as dotcms-js: utils has no build target and is tag-excluded from lint and test, so nothing in CI verifies these flags. Accepted trade-off, consistent with #35939.

Blast-radius verification

data-access (strict consumer) went from 68 type errors to 36, zero new. utils-testing (strict) unchanged at its 1 pre-existing error — the Omit did not break its EMPTY_SYSTEM_FIELD spread.

---

sdk-create-app (#35938)

Two errors, both from flags beyond plain strict:

• src/index.ts:393 — process.env.DEBUG needs bracket access under noPropertyAccessFromIndexSignature (TS4111). It is the only process.env.* dot access in the project.
• src/utils/index.ts:41 — fetchWithRetry tripped noImplicitReturns (TS7030). The loop returns on success and throws on the last attempt, but with retries < 1 the loop never runs and the function fell through returning undefined. Its only caller (isDotcmsRunning, src/index.ts:506) already guarded with if (res && …), so nothing broke in practice — but the signature was lying. Throwing after the loop closes the gap and narrows the return type to Promise<AxiosResponse>.

No build or CI wiring was needed here. The @nx/esbuild:esbuild executor type-checks before bundling (skipTypeCheck defaults to false and is not overridden), and CI already builds this project via nx run-many -t build (build-test in core-web/pom.xml). The same build runs in the SDK release pipeline (cicd_release-sdk.yml → nx run-many --projects='sdk-*'), so the flags are enforced on every release.

---

sdk-types (#35935)

libs/sdk/types/tsconfig.json has carried strict: true plus the four extra safety flags since the library was created (#31967), and tsc --noEmit passes with zero errors. It is also already enforced: tsconfig.lib.json sets "declaration": true, so @rollup/plugin-typescript sits in the Rollup chain and fails the build on a strict violation.

So no code change was required. What was missing was documentation, added here to core-web/CLAUDE.md:

• A ## TypeScript Strict Mode section covering the per-project flags, what actually enforces them, and the Vite exception (esbuild skips type checking, which is why the Nx Vite plugin infers a separate typecheck target).
• Fixes a line that forbade "strict": true in project tsconfigs. It sat under the Jest config guidance but read as a blanket ban, contradicted docs/frontend/TYPESCRIPT_STANDARDS.md, and blocked the epic outright. The restriction now points at tsconfig.spec.json, which is what it meant.

---

---

utils-testing (#35944)

The six strict flags were already in tsconfig.json — but completely inert. tsconfig.lib.json declared "types": ["jasmine"], that package is not installed, so tsc emitted TS2688: Cannot find type definition file for 'jasmine' and stopped before semantic checking. The project reported exactly one error regardless of what the code did.

The reference was stale: nothing uses jasmine, two files use jest.*, and @types/jest is installed. Switching to "types": ["jest"] removed the abort and 27 spurious Cannot find name 'jest' errors, leaving 5 real ones:

Site	Fix
clean-up-dialog.ts	Untyped fixture param → typed structurally as { nativeElement: unknown }, since only that property is touched (no need to pull in Angular's ComponentFixture)
dot-page-state.service.mock.ts	_lock: boolean = null → boolean | null
dot-page-tools.mock.ts ×3	Mock entries carried a tags array that DotPageTool does not declare. Verified nothing in the repo reads .tags off a page tool, so the dead field was removed rather than added to the model in dotcms-models

tsc -p libs/utils-testing/tsconfig.lib.json --noEmit now exits 0 with no CLI overrides — the check is real rather than short-circuited.

Verified across consumers of the touched mocks (cleanUpDialog in 7 files, page-tools mock in 3): data-access 751 tests passed, edit-ema-ui 338 passed.

---

dotcms-webcomponents (#35943) — groundwork only, not closed

Strict is not enabled here. ~250 errors remain across 38 files, and unlike the other projects this one has no skip:build, so Stencil type-checks it on every PR — flipping the flag early turns CI red. What landed is the part that is correct on its own.

The decorator split, which is the load-bearing decision. Stencil declares runtime-injected members without initializers, colliding with strictPropertyInitialization (139 of the original 375 errors). The fix cannot be uniform:

Decorator	Count	Fix	Why
@Event	57	!	Internal; the runtime creates the EventEmitter
@Element	27	!	Internal; the host element
@State	25	!	Internal component state
@Prop	30	?	Public API

Using ! on @Prop made Stencil emit 28 props as required in components.d.ts — breaking for any TS/JSX consumer. With ? the generated API moves required → optional, which is backward compatible. Measured in the generated file, not assumed.

Two traps recorded on the issue

Stencil under-reports. Its build shows ~10 files / ~39 errors per run, not the total. Measured at the same commit: Stencil 39 errors / 10 files vs tsc 250 / 38. Size this work with tsc, not with build output.

--skip-nx-cache does not clear Stencil's cache. Builds can report green against stale .stencil output. This bit me: 0117273504 annotated a prop, passed a "clean" build, and was actually broken — reverted in f22afce383 after verifying twice with .stencil and the Nx cache cleared.

That prop (dot-binary-text-field's value) is genuinely contradictory: handleFilePaste assigns a File, other paths assign strings, and the template feeds it to an <input value> that accepts neither. No annotation describes the current code — the render path has to be fixed first. Left untyped with a TODO(#35943) so it is not re-annotated in isolation.

---

sdk-react (#35945)

strict: true was already present; the five companion flags were not. Adding them surfaced 14 errors, all TS4111 — dot access on a type carrying an index signature — resolved with bracket notation. Two origins, same fix:

• 13 from node.attrs, declared Record<string, any> in @dotcms/types. That type is deliberately left alone: block editor attributes really are dynamic, and it lives in a layer-0 project whose consumers would all be affected.
• 1 from CSS Modules (styles.row in Row.tsx), whose generated type is also a Record<string, string>.

No behaviour change — bracket access compiles to the same property lookup.

The flags here are genuinely enforced, and that was proved rather than assumed. Reverting one access to dot notation fails the build with @rollup/plugin-typescript TS4111, confirming TypeScript sits in the Rollup chain. The project carries no skip: tags, so CI builds, lints and tests it on every PR, and the same build runs in the SDK release pipeline.

One error remains under plain tsc and is expected: Cannot find module 'virtual:sdk-version' in sdk-client — a Vite virtual module that raw tsc cannot resolve but the build can. It predates this change and is unrelated to strict mode. Worth knowing when measuring, or the count reads 15 instead of 14.

---

sdk-analytics (#35946)

Same starting shape as sdk-react: strict: true already present, the five companion flags absent. But this one is not enforced, and that was established by test rather than inference.

18 errors in production source, all TS4111 from noPropertyAccessFromIndexSignature — dot access on HTMLElement.dataset (DOMStringMap) and on a Record<string, unknown> of payload properties. Bracket notation throughout, reads and writes alike. Spread across dot-analytics.utils.ts (10), dot-analytics.click-tracker.ts (4), dot-analytics.impression-tracker.ts (3), dot-analytics.click.utils.ts (1).

29 errors in specs — 15 more of the same mechanical dataset fix, plus 14 that were pre-existing drift rather than strict-mode fallout. Confirmed pre-existing: they persist identically under --strict false. Two independent gaps had let them accumulate unseen — the inferred typecheck target runs only tsconfig.lib.json, and jest.config.ts transforms via babel-jest, which strips types without checking them.

Root cause	Count
ANALYTICS_CONTENTLET_CLASS no longer exported — renamed to CONTENTLET_CLASS	2
Pageview fixture put device inside data and omitted required locale_id	4
Untyped jest.fn() inferring never for mockResolvedValue / mockRejectedValue	3
Location mock missing host	1
jest.spyOn(...).mockImplementation() called with no argument	2
mockInitialize inferred as zero-arg	1
result.custom — not on EnrichedTrackPayload	1
TS2589 excessively deep instantiation	1

The pageview fixture was the instructive one: with device misplaced and locale_id missing, the pageview member of the DotCMSEvent union stopped matching, so TypeScript fell through to the impression member and reported a misleading "doc_encoding does not exist on DotCMSContentImpressionPageData". One coherent fix cleared four errors. Fixtures were corrected rather than production types widened; no source bug hid behind any of them.

⚠️ Negative test says the build is not a gate. Unlike sdk-react, this project builds through Vite. It does run dts({ tsconfigPath: 'tsconfig.lib.json' }) with vite-plugin-dts@4.5.4, which invokes the TS compiler to emit declarations — so the build plausibly could have enforced the flags. It does not: a deliberate const __strictProbe: number = "definitely not a number"; in a lib source file did not fail nx run sdk-analytics:build --skip-nx-cache. vite-plugin-dts emits declarations without failing on diagnostics, and CI never invokes typecheck. Probe reverted immediately.

So sdk-analytics joins dotcms-js and utils as strict but unenforced. Wiring nx affected -t typecheck into core-web/pom.xml was deliberately left out — it is monorepo-wide and belongs to the epic, not to project 13 of 44. Both gaps are raised on #35932.

This also corrects the pattern proposed in #35942 — that every libs/sdk/* project was already strict and already enforced. That holds for the Rollup-built SDK libs, which type-check through @rollup/plugin-typescript (as sdk-react proved). It does not hold for Vite-built ones: sdk-analytics inherited strict from the shared tsconfig lineage but neither the other five flags nor a type-checking build.

0 internal dependents — the only references to @dotcms/analytics outside the lib are doc comments in libs/sdk/uve/src/internal/constants.ts. No blast radius.

---

sdk-angular (#35947)

No flags were added — all six were already there, plus Angular's strictTemplates, strictInjectionParameters and strictInputAccessModifiers. Re-adding them would have been a cosmetic diff. The real defect was dead config.

Both tsconfig.lib.json and tsconfig.spec.json referenced a next/ directory that existed and was removed — the references landed on 2025-03-21 (09e879b2ac) and outlived the directory. One of them was fatal:

error TS6053: File '.../libs/sdk/angular/next/test-setup.ts' not found.
  The file is in the program because:
    Part of 'files' list in tsconfig.json

tsc aborts on that before semantic checking, so tsconfig.spec.json had never completed a single semantic pass and any error count taken from it was meaningless. The asymmetry is the lesson: a non-matching include glob is harmless, a missing files entry is fatal — which is why tsconfig.lib.json, whose next/ references were only in include/exclude, kept working.

Removed the dangling references from both. Both configs now report 0 own errors; the one remaining error in each is the pre-existing, unrelated virtual:sdk-version from sdk-client documented in the sdk-react section above.

The spec config coming out clean was predicted, not lucky: jest-preset-angular@17 → ts-jest@29.4.6 with diagnostics enabled and transpile-only unset already type-checked all 21 spec files against these exact compilerOptions — just per-file, never as a whole program. That is the opposite of sdk-analytics below, where babel-jest stripped types and hid 14 errors. Same rollout, two projects, and the test transformer decided whether anything was checked at all.

✅ Negative test confirms the build is a real gate. A deliberate const __strictProbe: number = "definitely not a number"; in lib/store/dotcms.store.ts fails nx run sdk-angular:build with TS2322 and exit code 1 — @nx/angular:package runs ngtsc. Probe reverted, file byte-identical to git. No typecheck target was added; per CLAUDE.md that is redundant when the build already type-checks.

Production source is clean without escape hatches: 0 @ts-ignore / @ts-expect-error, 0 non-null assertions, and 2 anys that are the same exported declaration (DynamicComponentEntity = Promise<Type<any>>, lib/models/index.ts:12). Type<any> is idiomatic Angular for dynamically-loaded components and the type is public API, so narrowing it is a separate change, not strict-mode work. 0 internal dependents.

CLAUDE.md now documents the TS6053 masking variant next to the existing TS2688 one. Two of the fourteen projects triaged so far were masked this way — #35944 via TS2688, #35947 via TS6053 — so error counts from the remaining projects should not be trusted until their tsconfigs are checked for this.

---

data-access (#35948)

First non-isolated project in the rollout: 27 direct dependents, 6 of them already strict.

All six flags had been in libs/data-access/tsconfig.json for some time, and they were completely inert. The project has no build target, so its own tsconfig is never read by anything, and 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 — matching the 106 → 68 → 36 drift measured incidentally in the dotcms-js and utils sections above.

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

Production source (36)

• paginator.service.ts (14) — 8 uninitialised fields given zero values; four header reads take ?? '' (identical NaN outcome); private setLinks(linksString: string) widened to string | null since its body already did linksString?.split(',') || []; 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 rather than defaulted. getParams() gates the direction query param on truthiness, and OrderDirection.ASC === 1 is truthy where undefined was not — defaulting it would have made every paginated request in the admin UI start sending a param it previously omitted.

• dot-page-state.service.ts (12) — six declarations widened because they were simply wrong; the service really does emit null. The interesting one is handleSetPageStateFailed, declared Observable<DotHttpErrorHandled> but ending in map(() => undefined). Because it genuinely emits undefined, 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 instead of fighting an annotation. if (page) became if (page && user) — which forkJoin already guaranteed.
• dot-router (5), dot-localstorage (3), dot-content-types-info (2) — nullable getters (previousUrl, storedRedirectUrl), localStorage reads, and a string index narrowed to keyof.

Specs (47)

25 came from three lines. The fake Router declared navigate = jest.fn(() => ...), which infers zero parameters, so every toHaveBeenCalledWith(...) was a TS2554.

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

Two of the rest 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.

Also: dot-page-layout.service.spec.ts was calling save(id, mockDotLayout()), but save takes a DotTemplateDesigner and posts it verbatim — the spec was testing a payload shape production never sends (edit-ema-layout.component.ts:111 sends the real one). And the dot-content-drive fixture used an offset field removed from DotContentDriveSearchRequest, copied from the model's own stale JSDoc example, which is fixed here too. dot-personas now reuses the existing mockDotPersona from @dotcms/utils-testing instead of hand-rolling 21 fields.

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

Blast radius — measured, not assumed

Every strict dependent was counted before and after. Zero new errors, 218 removed, and three went fully clean because 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

This is the "high leverage" the issue predicted, quantified.

⚠️ Still unenforced, consistent with dotcms-js and utils above — no build target, so nothing catches a regression of these 83 fixes. That is now four projects in this state; raised on #35932 rather than solved per-project.

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

data-access 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/.../config/config-set.js:229 reads TypeScript's isolatedModules into ts-jest's own flag.
• ts-jest/.../compiler/ts-compiler.js:74 builds the language-service host only if (!isolatedModules).
• _doTypeChecking() needs that host for getSemanticDiagnostics.

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 — so "tests pass" has never been evidence of spec type-cleanliness. This corrects the justification given in the sdk-angular section above (that verdict was separately confirmed with tsc -p, so it stands). Removing the flag would enable checking monorepo-wide and is left to the epic.

---

Batch two: twelve more projects (#35949 #35950 #35951 #35952 #35954 #35960 #35962 #35963 #35965 #35968 #35969 #35970)

Bottom-up, and the ordering mattered more than the raw counts suggested.

libs/ui first, because it was the bottleneck (#35953 — still open)

ui had none of the six flags and 549 own errors, and ~109 of them leaked into each of its 26 dependents. Clearing its library program collapsed the portlets that follow:

Project	Before ui	After
portlets-dot-usage	219	0
portlets-dot-tags-portlet	238	22
portlets-dot-locales-portlet	243	27
portlets-dot-es-search-portlet	246	30
portlets-dot-categories-portlet	249	33
portlets-dot-analytics	266	50
content-drive-ui	275	59

ui's tsconfig.lib.json is at 0 (from 122) and its tsconfig.spec.json at 90 (from 427), so #35953 stays open. Notable findings there:

• dot-icon's size became size?: number rather than = 0, because the template binds [style.font-size.px]="size" and 0 would have rendered invisible icons where undefined inherits.
• dot-sidebar, dot-dropdown, dot-site-selector, dot-container-options and dot-trim-input all inject their host with { optional: true } and then used it unguarded. They now guard.
• Types that were wrong rather than merely loose: formEl was declared HTMLFormElement while the template says #formEl="ngForm"; getVariableIndexChanged declared number while its own JSDoc documented number | null.
• A real defect: dot-add-to-bundle invoked getDefaultBundle twice for the same value.
• tsconfig.lib.json excluded a non-existent src/test.ts but not test-setup.ts, **/*.test.ts or __mocks__/, so test files were being compiled into the library program — 15 errors by itself.
• Specs went 427 → 90 mostly by asserting at the point of declaration: 53 usages of one select local came from a single line.

Already compliant, verified rather than assumed

#35950 portlets-dot-locales-data-access and #35952 portlets-dot-experiments-data-access needed no change: all six flags present, both configs at 0, and neither masked by a TS6053/TS2688 config error. Both reported 36 errors before #35948 — purely data-access leaking.

#35949 sdk-experiments was a flags-only change. The cost was measured on the CLI before committing (0 with all six), and enforcement was proved by negative test: it builds with Rollup, so a deliberate type error fails the build with @rollup/plugin-typescript TS2322.

Barrel files that only their consumers could see

#35951 global-store re-exported WebSocketStatus — a type — with export {}, which is TS1205 under isolatedModules. Its own configs never reported it, because no spec there imports ./index, so the file was never in its own program. It surfaced only from consumers, showing up as the single spec error attributed to #35954 portlets-dot-analytics-data-access. One export type closed both issues.

Third and fourth instances of this shape followed in dot-analytics's two barrels. A barrel can carry an isolatedModules error that only its consumers ever see — worth a repo-wide sweep, raised on #35932.

An ambient declaration in the wrong place

The htmldiff-js declaration added for ui lived under libs/ui/src, so it was only in ui's own program and every consumer still reported TS7016. It is now registered through tsconfig.base.json from a root-level types/ folder — inside libs/ui made @nx/enforce-module-boundaries demand a relative import. Same shape as the known virtual:sdk-version leak from libs/sdk/client.

Signal stores are the dominant spec pattern

#35968 dot-tags (18 of 22), #35963 dot-es-search (all 28) and #35962 dot-categories (15 of 31) were all the same theme: a Signal<T> does not structurally overlap a jest.Mock, so casts must route through unknown, and assignments of jest.fn() onto signal-typed members must state the type they stand in for.

dot-categories also had fixtures incomplete in two directions — DotCMSAPIResponse needs four fields beside entity (now a shared API_ENVELOPE rather than repeated nine times) and DotCategoryDeleteResult needs deletedCount — plus four calls passing Event where openRowMenu takes a MouseEvent.

Wrong annotations, not loose ones

#35965 dot-locales: both dialog refs were annotated DynamicDialogRef, but DialogService.open() is typed as possibly null in this PrimeNG version. Its store spec mocked Observable<void> methods with of(null).

#35960 edit-content-bridge: the dialog ref is now captured in a local so its non-nullness is evident rather than asserted. In its spec, reconcileOnFormEvent is assigned inside a nested callback, which control-flow analysis cannot see, so TypeScript narrowed it back to null and called it not callable.

#35969 portlets-dot-usage: one fixture missing UsageSummary.lastUpdated.

The first app, and what it revealed about templates

#35970 dotcdn had 19 errors, and 8 shared one cause: dispatchLoading's switch had no default, so under noImplicitReturns the updater's return type included undefined, it stopped resolving as a one-argument updater, and all six call sites reported TS2554: Expected 0 arguments. default: return state fixed all eight.

More importantly, its build failed on libs/ui's templates, not on dotcdn:

libs/ui/.../dot-action-menu-button.component.html:1:14 - error TS2532: Object is possibly 'undefined'

libs/ui has no build target, so its templates had never been null-checked — they are only verified when a consuming app compiles them.

tsc -p does not check templates. Every per-project count in this rollout taken that way misses the class entirely. Probed across the three remaining apps by temporarily enabling the flags and building: 2, 8 and 23 template errors against 350–2500 .ts errors. Real, but ~1% of the volume, so it does not change the plan. Reported on #35932.

dotcdn and edit-content-bridge both have build targets, so their flags are genuinely enforced. The rest of this batch is not — no build target, and :test does not type-check.

Dependencies

Added @types/d3-scale, @types/d3-selection and @types/d3-shape. All three d3 packages are direct dependencies with no bundled types, so those imports were implicitly any. Maintained DefinitelyTyped packages, so installing beats hand-declaring the modules.

---

Batch three: libs/ui finished, plus four more (#35953 #35956 #35959 #35961 #35966)

libs/ui (#35953) — 549 → 0, and it unblocked most of what followed

Both configs are now clean: tsconfig.lib.json 122 → 0, tsconfig.spec.json 427 → 0. ~109 of its errors leaked into each of its 26 dependents, so clearing it collapsed seven projects from 219–275 down to 0–59. portlets-dot-tags-portlet had 1 error of its own, not 238.

Highlights beyond the mechanical work:

• Types narrower than their own implementation. DotLocaleTagPipe guards with if (!languageId || !languagesMap), DotRelativeDatePipe with const time = date || Date.now(), and onAssignChange/onCommentChange with ?? '' — all three declared non-nullable parameters, making those guards unreachable and the specs that assert the null behaviour uncompilable.
• A type contradicting the API. DotLanguageVariableEntry declared every language's value as always present; the API omits languages without a variable and the component already reads them with ?.value.
• A spec referencing a removed type. dot-browsing.service.spec imported SiteEntity, which no longer exists — dot-site.model.ts says to use DotSite, and createFakeSite already returns it.
• Real defects: dot-add-to-bundle invoked getDefaultBundle twice for the same value; five directives injected their host with { optional: true } and used it unguarded; formEl was declared HTMLFormElement while the template says #formEl="ngForm".
• Test files were in the library program. tsconfig.lib.json excluded a non-existent src/test.ts but not test-setup.ts, **/*.test.ts or __mocks__/ — 15 errors by itself.

Two techniques worth reusing: fix at the point of declaration (53 usages of one select local came from a single line; 95 declaration-level assertions cleared ~300 spec errors), and read each TS2564 site rather than applying the policy blindly — dot-icon's size became size?: number instead of = 0, because the template binds [style.font-size.px]="size" and 0 renders invisible icons where undefined inherits.

dot-plugins (#35966) — reported 733, had 63

tsconfig.spec.json used module: "commonjs" + moduleResolution: "node10", and tsconfig.json was missing moduleResolution: "bundler". node10 cannot resolve the @dotcms/* subpath exports, so 256 imports failed and everything downstream collapsed to unknown (227 TS2571, 115 TS18046, 85 TS2339). Aligning both with dot-tags took it from 733 to 1.

Swept the other remaining projects — dot-plugins was the only one affected. So the large counts for block-editor, dot-rules, edit-content and edit-ema-portlet are real work.

libs/portlets/CLAUDE.md was telling people to configure it that way. Its anti-patterns table said to omit strict: true ("causes issues with Angular compiler") and to use "module": "commonjs" in tsconfig.spec.json — while dot-tags, which the same guide calls the canonical reference, carries both strict: true and module: "preserve" and compiles clean. Corrected, so the next portlet does not repeat it.

dot-analytics (#35961) and content-drive-ui (#35959)

Spectator's typed props disagrees with Angular for aliased signal inputs. Components declare $tableState = input.required({ alias: 'tableState' }). Spectator's InferInputSignals keys off the field name; Angular's setInput requires the alias. The specs passed the alias under an as unknown cast that made the props bag unknown, so removing it surfaced TS2561 with a "did you mean $tableState" hint — and following that hint broke 12 tests. The alias wins; the cast is narrowed to the props type derived from the factory, with a comment naming the conflict.

A drop with no destination. dot-tree-folder's onDrop read the nullable $activeDropNode() and emitted it as targetFolder, which both payload types declare non-null. A drop outside any folder emitted an invalid event; it now returns early.

Also: two more barrels re-exporting types with export {} (third and fourth instances after #35948 and #35951), and @types/d3-scale / @types/d3-selection / @types/d3-shape added — direct dependencies with no bundled types.

new-block-editor (#35956)

38 of 60 were TS4111 on TipTap node attrs, converted from the exact positions tsc reports. EditorView is annotated from @tiptap/pm/view, not top-level prosemirror-view — the file's own comment explains that TipTap 3.x nests its own copy and mixing the two yields TS2322; the comment now names the correct source instead of saying the import is avoided entirely. Three plugin state fields had init: () => null, pinning the state type to null. @types/turndown added.

On my own mistakes in this batch

Three self-inflicted breakages, all from over-broad regexes, all caught by running the suites: contentlet?.asset → contentlet?['asset'] (invalid syntax, which then masked every other error), a (view) replacement that hit call sites as well as declarations, and — the one that mattered — "completing" a fixture that deliberately omitted Action.name, which is exactly the case its test asserts on. tsc was happy with that last one; only the test caught it.

Dependencies added in this batch

@types/d3-scale, @types/d3-selection, @types/d3-shape, @types/turndown. All four are direct dependencies whose imports were implicitly any; these are maintained DefinitelyTyped packages, so installing them beats hand-declaring the modules.

Batch four: block-editor (#35955)

The first of the four large projects. Estimated at ~743 own errors; the real figure was 442 — clearing libs/ui had already removed ~300 of them without this project being touched. No inherited errors at all, so all 442 were local.

block-editor has no build target, so tsc -p on tsconfig.lib.json and tsconfig.spec.json is the acceptance test. There is no build to lean on.

Four wrong declarations, not 442 unrelated fixes

DotMenuItem extends Omit<MenuItem, 'icon'> erased every declared member of MenuItem. PrimeNG's MenuItem carries a [key: string]: any index signature, so keyof MenuItem is string | number, and Exclude<string | number, 'icon'> removes nothing — Omit collapsed the type to its index signatures alone. id, label, command, disabled: all silently any. I probed it rather than assuming:

type Omitted = Omit<MenuItem, 'icon'>;
declare const viaOmit: Omitted['label'];    // any                → tsc reports nothing
declare const viaDirect: MenuItem['label']; // string | undefined → tsc reports it

MenuItem already declares icon?: string, so the omission bought nothing. Extending it directly cleared 12 TS4111 and gave every consumer real types back.

ImageNode referenced itself. addCommands used ImageNode.name inside ImageNode's own initializer, so TypeScript typed the whole extension any (TS7022). this.name is the same value and breaks the cycle — which then exposed a real Map inference problem in DotBlockEditorComponent._customNodes that the any had been hiding.

loadCustomBlocks had the wrong element type. Declared PromiseSettledResult<AnyExtension>[], but import(url) yields a module namespace — the element type is Record<string, AnyExtension>.

editor.storage.dotConfig was optional although getEditorExtensions() registers DotConfigExtension unconditionally, first in the list. Existing readers were split between ! and ?.. Declared required, and dot-config.types.ts — an unreferenced duplicate of the same module augmentation — deleted, since two copies that must stay in sync is exactly how this drifts.

Deleted rather than initialised

Two fields were never assigned and never read: FloatingActionsView.element and AIImagePromptView.tippyOptions. Giving them an initializer to satisfy TS2564 would have preserved dead code.

Seven errors were already present without any strict flags, two of them broken references:

• asset-form.component.spec.ts tested ImageTabviewFormComponent, a component that does not exist on main either. Deleted.
• dot-upload-asset.component.spec.ts imported DotUploadFileService from block-editor's shared barrel instead of @dotcms/data-access, so it provided a different token than the component injects.

Flagged, not changed

FloatingActionsView.update calls this.render().onExit(null), but ActionsMenu's onExit destructures editor from its argument. Preserved exactly, behind a cast and a FIXME(#35955) — changing runtime behaviour does not belong in a type-only pass.

placeholder.plugin keeps tr.getMeta(this). It looks wrong, but ProseMirror binds a state field's apply() to the Plugin instance, which is what makes it match the tr.setMeta(PlaceholderPlugin, …) calls. Annotated the this parameter to record that.

The test suite was already red — and stayed exactly as red

block-editor:test fails 16 suites / 37 tests on main. libs/block-editor is byte-identical between main and this branch, so this is Angular 22 migration debt, not something the epic introduced. Now tracked in #37091.

Per the agreed scope, this PR is types-only and left the suite alone. I verified that by name, not by count — a different set of 37 failures would have the same total:

=== only BEFORE (fixed by my changes) ===
=== only AFTER (new failures = regressions) ===

Same 38 entries, nothing added, nothing accidentally fixed. The cost is real and worth stating plainly: for this project I had no runtime safety net, which is the guard that caught my worst mistake earlier in this PR.

Dependents

Measured by checking out libs/block-editor at 82dbf4c9ad and re-running each dependent's tsc -p, so the delta isolates this change from the rest of the branch.

Dependent	Before	After
dotcms-block-editor	1	0
dotcms-ui	1	0
edit-ema-ui	2	0
edit-content	29	27
portlets-edit-ema-portlet	190	188

Zero new errors; three cleared outright.

dotcms-block-editor (#35973) — and the template gate block-editor never had

Three of this app's tsconfigs — spec, editor and the shared tsconfig.json they extend — declared "types": ["jasmine", "node"]. @types/jasmine is not installed, nor are karma-jasmine or jasmine-core, so each aborted with TS2688 before semantic checking. None had ever type-checked anything. The @angular/build:karma test target cannot run for the same reason, and the app has no .spec.ts files at all.

With that removed and the flags added, tsc -p was clean on all three — and the build failed:

TS2339: Property 'contentlet' does not exist on type 'never'
  libs/block-editor/.../suggestions-list-item.component.html:1:35

SuggestionsListItemComponent.data was declared = null, which under strict infers the type null, so data?.contentlet narrowed to never. Typed properly now.

The wider point: libs/block-editor has no build target, so its templates had never been type-checked by anything. tsc -p does not check templates, and it was the only gate #35955 had. #35973 is what puts them under a real one — which is why closing a small app mattered more than its error count suggested.

A spec file that disabled type checking across three libraries

While measuring #35974, libs/edit-content/.../dot-edit-content-field.component.spec.ts turned out to declare:

/* We need this declare to dont have import errors from CommandType of Tiptap */
declare module '@tiptap/core' {
    interface Commands {
        [key: string]: { [key: string]: (...args) => any };
    }
}

Module augmentations are global to the program. This one gave TipTap's Commands a string index signature for every file compiled alongside it — which is how editor.chain().focus(), a real declared command, became "Property 'focus' comes from an index signature".

edit-content's program pulls in 249 files from block-editor plus all of new-block-editor, so under strict flags it produced 256 errors in those two libraries' sources (149 + 107). Both compile clean under their own configs, so nothing could see it until a consumer went strict.

The comment's premise no longer holds: measured with the augmentation present and absent on the current non-strict config, edit-content reports 27 lib / 48 spec errors either way. It suppressed nothing and cost 256 unchecked sites. Removed.

A sixth way to get a green signal that checked nothing

TS5101 (baseUrl) and TS5107 (moduleResolution: node10) are deprecation errors under TypeScript 6 — and, like TS2688 and TS6053, they abort before semantic checking. libs/dotcms-webcomponents reports 2 errors without --ignoreDeprecations 6.0 and 279 with it.

It cannot set the option in its tsconfig: Stencil bundles TypeScript 5.8.3, which only accepts "5.0", while the workspace runs 6.0.3, which requires "6.0". No single value satisfies both, so the CLI flag is mandatory — the comment there now says so, and core-web/CLAUDE.md records the general rule: any TS5xxx/TS6xxx/TS2688 error is a configuration error, and the count after it means nothing.

Batch five: edit-ema-ui (#35971) and template-builder (#35958)

Two projects taken to 0, both with tests green throughout and lint back at its clean baseline.

A fixtures file compiled as production code

template-builder reported 27 inherited errors, all Cannot find name 'jest' in libs/utils-testing. utils-testing was not the problem: tsconfig.lib.json excludes *.spec.ts but not src/**/utils/mocks.ts, so a fixtures file importing @dotcms/utils-testing was in the lib program under types: []. Only specs import it and it is not in the public barrel, so it is now excluded from the lib build. edit-content reports the same 27 from the same cause.

sidebar is null when empty, and the model never said so

DotLayout.sidebar and DotTemplateLayoutProperties.sidebar were both declared non-nullable while TemplateBuilderComponent deliberately clears them:

sidebar: layoutProperties?.sidebar?.location?.length // Make it null if it's empty so it doesn't get saved
    ? layoutProperties.sidebar
    : null,

Two specs assert it. Widening the shared model surfaced three unguarded reads in the store — which is the point — and had zero impact on the eight strict projects that consume DotLayout.

Nearly changing a wire payload

publishContentletAndWaitForIndex takes { [key: string]: string | number }, and dot-favorite-page.store sends inode: formData.inode || null. My first fix was ?? ''. The spec caught it, because it asserts the payload contains inode: null — the endpoint distinguishes null from an empty string. The signature was wrong, not the call; widened it in data-access.

Same shape in DotContentCompareStore, which piped httpErrorManagerService.handle(err) out of catchError into a switchMap typed for contentlets. A handled error is not a contentlet array; both blocks now complete with EMPTY.

Two of my own mistakes, both caught by tests

A wrong zero value. The bulk TS2564 pass turned @Input() showDiff: boolean into = false. The dotDiff pipe defaults to true and the store seeds showDiff: true, so false silently disabled diffing and broke 4 specs. "Boolean means false" does not hold when the consumer's default is not the zero value.

Spectator props keying. Renaming the key from the alias contentlet to the declared member $contentlet type-checks and then fails at runtime in 11 specs, because Spectator applies the alias while InferInputSignals types props by the member name. The cast is unavoidable; it now carries a comment saying so.

No production non-null assertions left behind

Bulk narrowing introduced 27 in edit-content and 9 in template-builder, each tripping @typescript-eslint/no-non-null-assertion — the rule that exists to discourage exactly that. All were reverted or converted:

• edit-content: reverted, errors put back on the remaining count where they want real guards
• template-builder: converted — two DialogService.open() results, three subGridOpts.children reads, one child.containers filter, and a resizestart handler that asserted a four-link GridStack chain optional at every step
• edit-ema-ui: five in dot-favorite-page replaced with form.controls['x'], which the form always builds

Batch six: edit-content (#35974) and the two it was blocking (#35976, #35967)

edit-content is the largest project closed so far after ui: 101 production errors and 208
spec errors to 0, with 27 phantom "inherited" errors removed at source. 112 suites / 2218 tests
unchanged; lint at its pre-existing 11-warning baseline.

Its tsconfig.spec.json carried explicit "strict": false and
"noPropertyAccessFromIndexSignature": false opt-outs, which were hiding 666 of the 944 errors
the specs really had.

The dominant pattern was not missing guards — it was declarations lagging behind code already
written for null. Six signalMethod handlers plus five utilities and BaseWrapperField.formControl
all opened with a !x guard while declaring the argument non-nullable.
RelationshipFieldStore.initialize had three comments saying "contentlet is null in manual
translation" over a type that said otherwise.

InputSignal<T> is not covariant. Widening BaseWrapperField to InputSignal<T | null> took
the count 74 → 94: all 17 subclasses would have needed byte-identical input types, and 5 legitimately
differ. The base only reads them, so it declares Signal<T | null> — that is covariant.

Two latent bugs the compiler surfaced: the workflow sidebar's Select button is not disabled, so
confirming without choosing emitted undefined through an output<string>(); and the category field
wrote undefined into the form value for selected categories with no inode.

Four fixtures could never have matched the code: canLock mocked with the raw HTTP envelope when the
service maps response.entity; getByInode mocked with the scheme-grouped shape; isDialogMode
mocked in three specs after being deleted from the store; and MultiSelect.valuesAsString, which does
not exist on PrimeNG 21 — so expect(...).toEqual(undefined) asserted nothing.

Three of my own changes were caught by the tests, and in each case the test documented the intent
better than the type did, so I changed my code rather than the assertion: a guard in
onCommentSubmitted (the test is named "should still call addComment … even if identifier is
undefined", and the adjacent tests assert the opposite for the history handlers); formValues: {}
where a spec asserts null; and a contentType guard that aborted the locales flow because the
fixture never set one — the guard is right, so the fixture now provides one.

Nine shared-model members were widened to admit the null the endpoints actually send (workflow
metadata/status/scheme, contentlet lockedBy/lockedByName, content-type field
defaultValue/values/rendered, categories description). Every reader already tolerated it and
the model was the outlier — WorkflowTask.status was the only non-nullable member alongside
belongsTo, description and dueDate, all three already annotated. Blast radius re-measured
across all 12 strict projects after every one: 0 errors.

Two things deliberately not done. DotCMSContentlet.title is genuinely nullable — two tests are
named "without title" — but widening it lights up 10 errors across block-editor and edit-ema-ui,
both already closed, so it needs its own issue. And onWorkflowActionFired did not get an inode
guard: it carries a comment warning that one silently blocks saving new content.

Also recorded on #35974: libs/edit-content has no build target, so its templates have never
been type-checked and its strictTemplates is inert — the same gap as libs/block-editor.

The two projects it was blocking land here too. dotcms-binary-field-builder needed no source
changes. portlets-dot-query-tool-portlet needed three signal-mock casts, and its combination of
noImplicitReturns without strict caught a TS7030 I had introduced in edit-content — a guard
that returned bare where the other path returns an Observable teardown.

---

Test plan

edit-ema-ui (#35971) and template-builder (#35958)

• tsc -p — 0 on lib and spec for both (from 119 and 141)
• edit-ema-ui:test — 20 suites / 343 tests green; template-builder:test — 15 suites / 148 tests unchanged
• Both projects' lint back at their clean baselines, with zero production non-null assertions added
• template-builder's 27 inherited errors traced to mocks.ts in the lib build, not to utils-testing
• After widening DotLayout.sidebar and the data-access payload signature: dotcms-models, data-access, ui, block-editor, edit-ema-ui, utils-testing, utils, global-store all still 0

dotcms-block-editor (#35973)

• tsc -p — 0 on tsconfig.app.json, tsconfig.spec.json and tsconfig.editor.json, all three of which previously aborted on TS2688
• nx run dotcms-block-editor:build — clean (it failed first, on a template defect tsc -p cannot see)
• libs/block-editor unaffected: 0/0, tests unchanged at 16 suites / 37 by name
• libs/new-block-editor unaffected: 0
• edit-content:test still green at 112 suites / 2218 tests after removing the poisoning augmentation

block-editor (#35955)

• tsc -p libs/block-editor/tsconfig.lib.json --noEmit — 0 errors (from 296)
• tsc -p libs/block-editor/tsconfig.spec.json --noEmit — 0 errors (from 443); 442 own errors deduped across both
• nx run block-editor:test — unchanged at 16 suites / 37 tests failing, verified by failing-test name: identical 38 entries before and after
• nx run block-editor:lint — unchanged at 11 errors, all in files this branch does not touch (git diff origin/main confirms)
• Five dependents re-measured against 82dbf4c9ad: zero new errors, three go to 0
• No build target on this project, so tsc -p is the gate — stated on the issue rather than implied

dotcms-js

• pnpm exec tsc -p libs/dotcms-js/tsconfig.lib.json --noEmit — 0 errors (from 38)
• All six already-strict consumers build green: data-access, global-store, portlets-dot-analytics, portlets-dot-analytics-data-access, portlets-dot-locales-portlet, utils-testing
• data-access typecheck: 106 → 68 errors, zero new
• dotcms-ui typecheck clean (one pre-existing unrelated error)
• dotcms-js lint went from 42 to 41 problems (still tag-excluded)

sdk-create-app

• tsc --noEmit clean on lib and spec
• nx run sdk-create-app:build / :lint / :test green
• CLI smoke test: node dist/libs/sdk/create-app/index.js --help works
• Negative test: reverting the DEBUG fix makes nx run sdk-create-app:build fail with TS4111 — confirming the build gate is real

sdk-analytics

• tsc --noEmit clean on tsconfig.lib.json (from 18) and tsconfig.spec.json (from 29)
• nx run sdk-analytics:typecheck / :lint / :build / :build:standalone green
• nx run sdk-analytics:test — 15 suites, 314 tests passed. Since jest never type-checked these specs, this was the real regression check on the fixture edits
• Negative test: a deliberate type error does not fail nx run sdk-analytics:build — this project's build is not a gate

sdk-angular

• tsc -p tsconfig.spec.json --noEmit now completes a semantic pass at all (previously TS6053), 0 own errors
• tsc -p tsconfig.lib.json --noEmit 0 own errors
• nx run sdk-angular:lint clean; :build green
• nx run sdk-angular:test unchanged at 21 suites / 234 tests — the guard that no file dropped out of the program
• Negative test: a deliberate type error does fail nx run sdk-angular:build (TS2322, exit 1) — ngtsc gates this project

data-access

• tsc -p tsconfig.lib.json --noEmit 36 → 0; tsc -p tsconfig.spec.json --noEmit 84 → 0
• nx run data-access:lint clean; :test unchanged at 79 suites / 754 tests
• Blast radius: all 7 strict dependents counted before and after — zero new errors, 218 removed, three went 36 → 0
• Runtime guard on the widened services: dotcms-ui 820 tests and ui 2184 tests pass
• nx affected -t build green for all 6 affected projects

Batch two

• tsc -p clean on lib and spec for [16/44] Enable TS strict mode in sdk-experiments #35949 [17/44] Enable TS strict mode in portlets-dot-locales-data-access #35950 [18/44] Enable TS strict mode in global-store #35951 [19/44] Enable TS strict mode in portlets-dot-experiments-data-access #35952 [21/44] Enable TS strict mode in portlets-dot-analytics-data-access #35954 [27/44] Enable TS strict mode in edit-content-bridge #35960 [29/44] Enable TS strict mode in portlets-dot-categories-portlet #35962 [30/44] Enable TS strict mode in portlets-dot-es-search-portlet #35963 [32/44] Enable TS strict mode in portlets-dot-locales-portlet #35965 [35/44] Enable TS strict mode in portlets-dot-tags-portlet #35968 [36/44] Enable TS strict mode in portlets-dot-usage #35969 [37/44] Enable TS strict mode in dotcdn #35970
• libs/ui library program 0; specs 90 and still open as [20/44] Enable TS strict mode in ui #35953
• Tests green and unchanged throughout: ui 820, categories 109, analytics 333, content-drive-ui 245, locales 102, es-search 83, edit-content-bridge 97, tags 20, usage 21
• dotcdn:build and edit-content-bridge:build pass — the two enforced projects in this batch
• Negative test: a deliberate type error fails sdk-experiments:build (Rollup TS2322)
• Template-error scope measured by probe across all three remaining apps (2 / 8 / 23), then reverted

Batch three

• libs/ui both configs 0 (122 and 427 before); lint clean; 81 suites / 820 tests unchanged
• dot-plugins 733 → 0; new-block-editor 60 → 0; dot-analytics 42 → 0; content-drive-ui 59 → 0
• Tests green and unchanged: ui 820, analytics 333, content-drive-ui 245, plugins 81, new-block-editor 57
• After libs/ui landed, re-verified the ten already-closed projects plus dotcdn for regressions
• Swept every remaining project's moduleResolution; dot-plugins was the only one misconfigured

Both

• pnpm exec nx format:check --base=origin/main green
• No new any / @ts-ignore / @ts-expect-error (verified by diff grep)

Note: neither sdk-create-app nor dotcms-js has usable tests. sdk-create-app has zero test files (passWithNoTests: true); dotcms-js has 3 spec files that do not run (skip:test, and tsconfig.spec.json fails on a pre-existing jasmine types error). A green :test means nothing for either — the real verification is compilation.

---

Correction: a verification false negative (review follow-up)

A review comment caught a real regression this PR introduced, and the reason it slipped through matters for how the numbers above should be read.

libs/utils-testing/tsconfig.lib.json declares "types": ["jasmine"], and that package is not installed. tsc therefore emits TS2688: Cannot find type definition file for 'jasmine' and stops before semantic checking. So tsc -p libs/utils-testing/tsconfig.lib.json --noEmit reports exactly one error no matter what the code does.

The utils section originally reported "utils-testing unchanged at 1 pre-existing error" as evidence of no regression. That measurement proved nothing — nothing was being type-checked. Running the same config with --types node reveals 33 errors, including a genuine TS2741 caused by retyping EMPTY_SYSTEM_FIELD to Omit<DotCMSContentTypeField, 'clazz'>: the mock at dot-content-types.mock.ts:71 spreads it and never supplies clazz.

Fixed by giving the mock clazz: DotCMSClazzes.TEXT; that config is now at 32 errors, all pre-existing and unrelated.

Because the mock has ~103 consumers whose tests do run in CI, the runtime-value change was verified rather than assumed — clazz went null (pre-PR) → absent (this PR) → TEXT:

• FieldUtil.isRow / isColumn / isTabDivider compare for equality and return false for all three values.
• There is no !field.clazz or field.clazz === null anywhere in the repo.
• Test runs: default-value-property 7/7; dot-content-types-edit 545 passed across 48 suites; data-access 751 passed across 79 suites.

The data-access figures reported elsewhere in this PR (106 → 68 for dotcms-js, 68 → 36 for utils) are not affected — that project has no unresolved types entry, so those runs were doing real semantic checking.

core-web/CLAUDE.md now documents this masking behaviour so the next person does not repeat it.

Other two comments

• sdk-create-app — the throw said "requires at least 1 retry", but retries is the total attempt count (for (i = 0; i < retries; i++)), so retries = 1 is one attempt and zero retries. Reworded to "attempt".
• CLAUDE.md verify snippet — hard-coded libs/<project>/tsconfig.lib.json, which resolves for neither nested projects (libs/sdk/create-app, which has no tsconfig.lib.json) nor apps (tsconfig.app.json). Replaced with a <projectRoot> placeholder and both caveats.

Notes for reviewers

Three sibling issues in this rollout turned out not to need the work as written, and were resolved separately:

• [03/44] Enable TS strict mode in dotcms #35936 (dotcms) and [04/44] Enable TS strict mode in dot-layout-grid #35937 (dot-layout-grid) — closed as not applicable. Both are dead libraries with zero consumers that do not compile today; removal is tracked in Remove dead core-web libraries (libs/dotcms, libs/dot-layout-grid) #36950.
• The epic description was updated (44 → 42 projects) and corrected: it documented a typescript-strict-plugin / tsc-strict approach that was dropped — the bootstrap [00] Setup typescript-strict-plugin baseline + CI gate #35933 closed without the plugin ever landing. Sub-issues still referencing npx tsc-strict or // @ts-strict-ignore carry stale acceptance criteria; [06/44] Enable TS strict mode in dotcms-js #35939's were corrected on the issue.

Closes #35971
Closes #35958
Closes #35973
Closes #35955
Closes #35966
Closes #35961
Closes #35959
Closes #35956
Closes #35953
Closes #35970
Closes #35969
Closes #35968
Closes #35965
Closes #35963
Closes #35962
Closes #35960
Closes #35954
Closes #35952
Closes #35951
Closes #35950
Closes #35949
Closes #35948
Closes #35947
Closes #35946
Closes #35945
Closes #35974
Closes #35976
Closes #35967
Closes #35944
Closes #35940
Closes #35939
Closes #35938
Closes #35935

[claude]

Claude finished @nicobytes's task in 6m 14s —— View job

---

Code Review — PR #36957 (TS strict mode rollout)

Reviewed the runtime-affecting changes across data-access, dotcdn, dot-rules, utils, and the whole block-editor cluster (which has no test safety net). The overwhelming majority of the diff is faithful type-only work — !/?/?? annotations, bracket-notation index access, type guards — and the data-access/dotcdn/dot-rules changes are careful and correct (the dot-condition-group event refactor actually fixes a latent bug where event.type reached dot-rule.component.ts:387/405 as undefined). One genuine regression stands out.

New Issues

• 🟡 Medium: core-web/libs/block-editor/src/lib/extensions/floating-button/plugin/floating-button.plugin.ts:126 — the maxWidth fallback of 250 is now defeated when the image node has no rendered <img>.
  • Before: maxWidth: image?.width - this.offset || 250 → when querySelector('img') returns null, undefined - 10 is NaN, and NaN || 250 falls through to 250.
  • After: maxWidth: (image?.width ?? 0) - this.offset || 250 → (undefined ?? 0) - 10 is -10, which is truthy, so || 250 never fires and tippy receives a negative maxWidth.
  • this.offset is 10 (line 67), so the image-missing path silently changed from 250 → -10. block-editor has no runtime test coverage, so this won't be caught by CI. Suggest maxWidth: image?.width ? image.width - this.offset : 250. Fix this →

Existing (from prior reviewer comments — still open)

• 🟡 Medium: core-web/libs/utils/src/lib/shared/FieldUtil.ts:33 — as @oidacra noted, EMPTY_FIELD.defaultValue, .hint and .values moved from null to undefined. JSON.stringify drops undefined keys, so COLUMN_FIELD/ROW_FIELD/TAB_FIELD (which spread this) now omit those keys on the wire instead of sending explicit null when a layout is saved via DotFieldService. Assumption: Jackson treats absent-key and explicit-null identically for these object fields (usual case). What to verify: confirm the content-type layout save endpoint doesn't distinguish them, then either keep null for these three or add it to the documented change list.
• 🟡 Medium: core-web/libs/dotcms-webcomponents/src/.../dot-material-icon-picker.tsx:22, dot-html-to-image.tsx:30, dot-time.tsx:77 — @oidacra flagged these @State/@Prop fields annotated ! while the component logic assigns/reads undefined (e.g. this.selectedSuggestionIndex = undefined, render() branching on !this.previewImg). Strict is not enabled for dotcms-webcomponents in this PR (groundwork only), so there's no current build impact — but per this PR's own !-for-runtime-injected / ?-for-optional rule these should be ?, and they'll error under strict once [10/44] Enable TS strict mode in dotcms-webcomponents #35943 flips it. Worth aligning now to avoid rework.

Notes (non-blocking, not flagged as bugs)

• actions-menu.extension.ts:536 (command: (props) => execCommand({ ...props, customBlocks })) and the table insert Number(value['rows']) coercion are real runtime changes but both are fixes — the floating-actions path previously reached getCustomActions(customBlocks) with customBlocks undefined, and the number control emits strings. Correct.
• dot-asset.service.ts:22 — the new Promise<Response>[] type is slightly optimistic given each promise ends in .catch((e) => e), but that .catch is pre-existing and runtime is unchanged, so it's a type-accuracy nit, not a bug introduced here.

Everything else in the diff checks out. Only the floating-button.plugin.ts:126 item is a regression this PR introduces; the rest are non-blocking.

[Copilot]

Pull request overview

This PR opts the sdk-create-app library into the workspace’s incremental TypeScript strict-mode rollout (issue #35932), and adjusts docs/runtime code to align with stricter typing and clearer failure modes.

Changes:

• Enabled strict TypeScript compiler flags for core-web/libs/sdk/create-app via its project tsconfig.json.
• Updated fetchWithRetry to throw when misconfigured with < 1 attempts to avoid an implicit undefined return path.
• Updated strict-mode rollout documentation and adjusted DEBUG env access to bracket notation for noPropertyAccessFromIndexSignature.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
core-web/libs/sdk/create-app/tsconfig.json	Enables strict compiler options at the project level for the strict-mode rollout.
core-web/libs/sdk/create-app/src/utils/index.ts	Adds an explicit throw path for invalid retries values in fetchWithRetry.
core-web/libs/sdk/create-app/src/index.ts	Switches DEBUG env access to process.env['DEBUG'] for strict-mode compatibility.
core-web/CLAUDE.md	Documents the strict-mode rollout procedure and clarifies portlet tsconfig guidance.