admin-rte: Enable TypeScript strict mode

[VPS-thodax]

Status quo

Strict mode is not enabled everywhere in this repo. packages/admin/tsconfig.base.json stops at noImplicitAny and strictNullChecks, so @dextinity/admin-rte runs without the remaining strict checks.

Change

Enable strict for the package. All four resulting errors come from strictFunctionTypes, which compares callback parameters contravariantly:

• ControlButton attaches onButtonClick to a button element, so the prop is typed with React's MouseEvent for HTMLButtonElement instead of the wider one for Element.
• useInlineStyleType annotated its click handler with the DOM's global MouseEvent instead of React's, so it did not match IFeatureConfig.
• createComponentSlot drops the generic of MUI's Select, which types the slot's onChange with an unknown value. useBlockTypes follows and narrows the block type where it is read.
• requiredValidator is no longer declared as a FieldValidator: its optional meta parameter makes the type invariant in the field value, so it could not be passed to a string-valued Field.

Verification

Compared the emitted .d.ts files against main. Three types change, none of them breaking: the two in the changeset sit in a contravariant position, so handlers and validators that type-checked before still do, and BlockChangeEvent is not reachable through anything exported.

@dextinity/admin, @dextinity/cms-admin, the demo admin and Storybook typecheck against the rebuilt package.

Further information

• Task: https://vivid-planet.atlassian.net/browse/COM-1079

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}

[VPS-thodax]

Is there a way to keep using the FinalForm typing? Keeping the final form types seems more correct

[VPS-thodax]

You were right, and it is now a FieldValidator again — 207fee8.

FieldValidator is invariant in the field value: FieldState both accepts it (change: (value: FieldValue | undefined) => void) and returns it, so FieldValidator<string | RawDraftContentState | undefined> is not assignable to FieldValidator<string>, which is what createRteField needs. A single instantiation therefore cannot work — but a generic one can:

export const requiredValidator = <T extends string | RawDraftContentState | undefined>(
    ...[value]: Parameters<FieldValidator<T>>
): ReactNode => { ... };

I verified the four candidates by compiling assignments rather than reasoning about it: the wide instantiation fails for FieldValidator<string>; an intersection of instantiations fails for a raw-state field; the generic satisfies both FieldValidator<string> and FieldValidator<RawDraftContentState>. It is also less restrictive than before for consumers, since it now fits either field value.

---

Generated by Claude Code

[VPS-thodax]

Notes on the three non-obvious changes

Why the Select event cannot stay SelectChangeEvent<DraftBlockType>

The Select in BlockTypesControls is not MUI's Select directly — it is built with createComponentSlot(MuiSelect), which does not forward MUI's generic. The slot therefore types onChange with an unknown value. Under strictFunctionTypes callback parameters are compared contravariantly, so a handler declaring a narrower value is not assignable to it. The event has to be typed the way the slot passes it.

Why the value is narrowed in useBlockTypes

DraftBlockType is a string, so the unknown value has to be narrowed before it can be used as one. DraftBlockType is not gone from the file — it still types the block type everywhere else; it just cannot type the event. Every block type MenuItem is keyed by its block type, so a non-string cannot occur in practice, and if it did it falls into the same branch as the empty selection. Behaviour is unchanged.

requiredValidator keeps the final-form typing

Per the review, it is a FieldValidator again, now generic over the field value:

export const requiredValidator = <T extends string | RawDraftContentState | undefined>(
    ...[value]: Parameters<FieldValidator<T>>
): ReactNode => { ... };

FieldValidator is invariant in the field value, because FieldState both accepts it (change: (value: FieldValue | undefined) => void) and returns it. A single instantiation therefore cannot serve both a string-valued Field (what createRteField needs) and a raw-state one. I compiled the candidates instead of reasoning about them:

Form	FieldValidator<string>	FieldValidator<RawDraftContentState>
single wide instantiation	✗	✓
intersection of instantiations	✓	✗
generic	✓	✓

So the generic is the only form that keeps the final-form type and works for either field value — and it is less restrictive for consumers than what is on main today.

---

Generated by Claude Code