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

Project	Deployment	Preview	Comments	Updated (UTC)
lexical	Ready	Preview	Comment	Sep 21, 2025 5:41pm
lexical-playground	Ready	Preview	Comment	Sep 21, 2025 5:41pm

This is a brilliant piece of work, particularly the API design, there's been many ideas around extensions/bundling plugins but this one is certainly the most complete that appears to ticks the most boxes. Thank you for writing this comprehensive multi-page documentation!

Thank you! There's more to write, but I really want to get something out there sooner than later and questions will drive where effort is spend on docs.

Admittedly, there's a lot going on here and didn't read line by line, but I wanted to share some high-level feedback to understand better.

configExtension(EmojiExtension, {
  emojiClass: "emoji-node",
  emojiLoadedClass: "emoji-node-loaded",
  emojiBaseUrl: "/assets/emoji",
}),

When is the configExtension required? How do users know? TS works well either way.

configExtension is only useful when you want to provide configuration overrides for the extension you're depending on. It's a convenience function that simply returns its arguments as an array, [EmojiExtension, {emojiClass: "emoji-code", …}] in this case. It's better to use a function for type inference because it's a non-empty tuple of extension followed by zero or more configuration overrides rather than some homogenous array.

/**
 * A tuple of `[extension, ...configOverrides]`
 */
export type NormalizedLexicalExtensionArgument<
  Config extends ExtensionConfigBase,
  Name extends string,
  Output,
  Init,
> = [LexicalExtension<Config, Name, Output, Init>, ...Partial<Config>[]];export function configExtension<
  Config extends ExtensionConfigBase,
  Name extends string,
  Output,
  Init,
>(
  ...args: NormalizedLexicalExtensionArgument<Config, Name, Output, Init>
): NormalizedLexicalExtensionArgument<Config, Name, Output, Init> {
  return args;
}

From the docs: No compile-time support for dependency resolution

Can we actually do this with TypeScript? Or would it require some build script?

It's possible but not really worth it because there are already several ways to get a very early runtime error while the editor is being constructed when there are conflicting names or a name matches something in a conflictWith from another extension.

It would really just make type checking slower, more fragile, harder to maintain, etc. for very little benefit.

I don't know if it's releated, but I still foresee the possibility of conflicting dependencies, especially in the case of 2 third parties that haven't seen in other. I recall we discussed this in the past, and I'm not sure if it's worrysome or a problem worth investing in further.

The recommendation of using scoped names should mostly eliminate the third party problem, two parties shouldn't publish extensions with the same scoped name. Realistically though there are much more insidious ways for extensions to conflict that we really can't do anything about (e.g. handling the same DOM events or commands in incompatible ways, the simplest of which would be that one handles it completely and prevents the other extension from seeing the event or command it needs to see).

How much did you get to test Flow? Is it a best effort? Since Meta is probably one of the few users, I don't think this is a blocker and we can test, and report/fix accordingly.

npm run flow is the only testing I did. I used npm run lint-flow to try and catch most of the new types, although I might've missed some. I did write them pretty much by hand for better or for worse, mostly by pasting the explicit or inferred typescript types and making the superficial syntax changes for flow compatibility. Adding more flow coverage should be pretty straightforward incremental work.

I'm stamping already since this is an idea that has been floating for some time and discussed in some sessions but I would value if others had a chance to read over it (at least the docs) and provide some feedback.

Would be great to get some more feedback! I don't think we'll hear much from non-maintainers until after it's released, which would be nice to do sooner than later. It would also let me clean up some of the hacks that the examples are using to reference packages that don't exist on npm.