Bob Ippolito
Bob Ippolito
@zurfyx I will write the flow types when/if there's general buy-in for this API, ideally that step would be the last iteration. Are you happy enough with how it looks...
The data returned by $config is used to implement a boilerplate static getType for backwards compatibility when the node is registered with an editor.
getType is only called there when the node class directly implements it (the hasOwn check) and it is not one of the three abstract base classes (DecoratorNode, ElementNode, and LexicalNode)....
Hard to say what the right workaround would be without knowing exactly how far Meta's implementation strays from the standard but if it respects the prototype chain correctly then something...
Of course this is only a valid workaround in the limited context for which this is used, so maybe it should be renamed to `hasOwnMethodOverride` or something like that so...
Your implementation of hasOwnMethod only works for static methods. The implementation uses hasOwn for both instance and static methods. Would need a separate workaround for instance methods. I don't know...
That should work fine
Why not add a variable like `__META_ONLY__` that you can use to isolate workarounds for the bugs in Meta's tool chain?
The inheritance chain issue is sufficiently solved by checking value equality with the LexicalNode or LexicalNode.prototype directly. It won't handle warning in all of the edge cases where you're subclassing...
I've created a PR #7659 that may address these issues