ChildNode/ParentNode no longer extending Node

According to https://github.com/microsoft/TypeScript/issues/45266, there are some breaks around ChildNode no longer being a subtype of Node. This was also mentioned in Google’s 4.4 beta adoption thread (#1067).

Some breaks here

ant-design/ant-design

tsconfig.json

• error TS2359: The right-hand side of an 'instanceof' expression must be of type 'any' or of a type assignable to the 'Function' interface type.
  • components/_util/scrollTo.ts#L26
• error TS2339: Property 'nodeType' does not exist on type 'ChildNode'.
  • components/typography/util.tsx#L143
  • components/typography/util.tsx#L207
• error TS2345: Argument of type 'ChildNode' is not assignable to parameter of type 'Node'.
  • components/typography/util.tsx#L160
  • components/typography/util.tsx#L165
  • components/typography/util.tsx#L220
• error TS2339: Property 'textContent' does not exist on type 'ChildNode'.
  • components/typography/util.tsx#L227

sindresorhus/refined-github

tsconfig.json

• error TS2345: Argument of type 'Element | ChildNode' is not assignable to parameter of type 'string | Node'.
  • source/helpers/dom-utils.ts#L48

In #1067, @saschanaz explained

It’s a mixin interface implemented by some Node interfaces. The correct way to receive Nodes that can be children is ChildNode & Node, just like ParentNode & Node for Nodes that can be parents.

I may be missing some context of why that’s important to have - was there discussion around that? But regardless, I don’t know if we can retroactively make that call. If that’s a thing users need, does it make sense to create a ChildNodeBase and a ParentNodeBase?

[DanielRosenwasser]

I wasn’t sure whether it was worth it to define the new *Base types, so I’ve left them out for now. I figured that if it’s really broadly needed, we could introduce them in 4.5.

[saschanaz]

That should implement your idea https://github.com/microsoft/TypeScript-DOM-lib-generator/issues/1087#issuecomment-891333791, or did you change your mind?