The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
lexical	Ready	Preview, Comment	May 12, 2026 8:40pm
lexical-playground	Ready	Preview, Comment	May 12, 2026 8:40pm

This should probably also be marked as a breaking change. Even though they were basically broken before you could still create empty inline ElementNodes before that had some behavior. Perhaps the right solution is to add transforms in RichTextExtension and PlainTextExtension that can be configured on or off (default on). This way anyone with legacy code that predates extensions would work as-is and people using a newer stack can still opt-out of the transform while they migrate their code.

I wonder if it would be better to just register a transform on ElementNode instead of adding more code directly to the update cycle

This cannot be done, at the very least because ElementNode does not implement the getType method and is not explicitly registered in the editor, which will cause an error. Additionally, registerNodeTransform handlers do not propagate to subclasses, unlike the $transform property in config(), but I'm not sure if ElementNode can be rewrite to config() without causing regression

There are plenty of ways to do it like just manipulating editor._nodes. We don't have to only rely on public APIs for internal functionality, e.g.

if (!config.disableEmptyInlineElementNormalization) {
  for (const {klass, transforms} of editor._nodes.values()) {
    if (klass.prototype instanceof ElementNode && klass.prototype.isInline !== ElementNode.prototype.isInline) {
      transforms.add(normalizeEmptyInlineElementTransform);
    }
  }
}

I set the default option to false for register functions and true for the extensions API. This way, the change won’t break users of legacy plugins, while extensions will immediately behave correctly, with the option to revert the change