[lexical-react] Bug Fix: ExtensionComponent support for output Components with required props#8472
Merged
etrepum merged 4 commits intoMay 7, 2026
Conversation
…s with required props
The ExtensionComponentProps inference used `infer T extends React.ComponentType`,
which defaults to `React.ComponentType<{}>`. Because component types are
contravariant in their props, any output Component declaring required props was
not assignable to `ComponentType<{}>`, so the conditional type collapsed to
`never` and the JSX element rejected every prop (including the extension
itself). Constraining the inference with `React.ComponentType<any>` lets the
inferred type retain its real prop shape.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…ents with required props
useExtensionComponent constrained its inferred OutputComponent through
`Props extends Record<never, never>` and `OutputComponent extends
React.ComponentType<Props>`, which collapses to `ComponentType<{}>`. Because
component types are contravariant in their props, an extension whose output
Component declares required props could not satisfy that constraint and
TypeScript rejected the call. Drop the redundant `Props` parameter and
constrain `OutputComponent` to `React.ComponentType<any>` so the inferred
component type retains its real prop signature. Also extends the existing
ExtensionComponent test suite to cover useExtensionComponent's return type.
… Components with required props
The conditional inferred the output Component as
\`infer C extends React.ComponentType\` (defaulting to
\`React.ComponentType<{}>\`), so any extension whose Component declared required
props failed the contravariant constraint and the conditional collapsed to
\`never\` — making the \`props\` field unassignable. Infer the prop type
directly via \`React.ComponentType<infer P>\` so contravariance never enters
the picture.
Adds type-level and runtime coverage for useExtensionDependency, useOptionalExtensionDependency, and usePeerExtensionDependency to confirm the returned `output.Component` retains its real prop signature (including required props) and that the optional hooks return `undefined | LexicalExtensionDependency` as documented.
ivailop7
approved these changes
May 7, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The ExtensionComponentProps inference used
infer T extends React.ComponentType, which defaults toReact.ComponentType<{}>. Because component types are contravariant in their props, any output Component declaring required props was not assignable toComponentType<{}>, so the conditional type collapsed toneverand the JSX element rejected every prop (including the extension itself). Constraining the inference withReact.ComponentType<any>lets the inferred type retain its real prop shape.This fix allows
<ExtensionComponent lexical:extension={SomeExtension} {...withRequiredProps} />to workDiscord discussion
Test plan
New unit tests to confirm that the types don't collapse to never