[35/44] Enable TS strict mode in portlets-dot-tags-portlet

[nicobytes]

Description

Part of the strict-mode rollout epic #35932. Enable TypeScript strict mode for the portlets-dot-tags-portlet project.

• Internal dependents: 1 · Rollout order: 35 / 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 (tsconfig.app.json for apps).
• 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, with the test count unchanged.
• nx affected -t build,lint does not break dependents.
• The enforcement status is recorded — i.e. whether any CI gate actually verifies the strictness.

⚠️ Three things established earlier in this rollout that make error counts untrustworthy:

• :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.
• tsc does not check templates. Only a build does, and most projects in this rollout have no build target ([37/44] Enable TS strict mode in dotcdn #35970).

Priority

Medium

Additional Context

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

[nicobytes]

Implemented — 22 errors, 18 of them one pattern

Corrected the stale ACs above first. Two flags were missing (strict, noPropertyAccessFromIndexSignature).

Config	Before	After
tsconfig.lib.json	2	0
tsconfig.spec.json	20	0

The 18

dot-tags-list.component.spec.ts casts store members with (store.x as jest.Mock). Those members are Signals, which do not overlap jest.Mock, so each cast now goes through unknown.

The real one

dot-tags-list.store.ts passed a catch binding straight to httpErrorManager.handle(). Under strict that binding is unknown, so the type it is being handed as is now named explicitly.

Shared context for this batch

All three portlets only became this small once libs/ui was cleared in #35953. Before that they reported 238, 243 and 246 errors respectively — almost entirely ui leaking through imports, not their own code.

The common theme across them is mocking signal stores in specs: a Signal<T> does not structurally overlap a jest.Mock, so casts between them have to route through unknown, and assignments of jest.fn() onto signal-typed members need to state the type they stand in for.

Results

Gate	Result
tsc -p lib / spec	0 / 0
:lint	pass
:test	pass — 20 tests

Not enforced: no build target, and :test does not type-check (#35948).

Shipped in PR #36957.