Return cloneNode as the receiver type

[Kelpy2004]

Summary

I updated the DOM override for Node.cloneNode so the generated DOM libs return the receiver type instead of the base Node type. This keeps existing Node behavior as Node, while preserving exact static types for DOM subtypes and custom element subclasses.

Addresses microsoft/TypeScript#283.

Why

cloneNode returns a clone of the node it is called on, but the current declaration forces callers to cast from Node even when the receiver has a more specific static type.

I also checked the prior cloneNode overload history before making this change. This patch uses one receiver-type return on Node rather than adding per-element overloads.

Validation

• npm run test
• npx tsc baselines/dom.generated.d.ts <@types/jquery> <@types/tablesorter> --target es2020 --lib es2020 --strict --noEmit --skipLibCheck false --typeRoots <scratch @types>
• npx tsc baselines/dom.generated.d.ts --lib es5 --noEmit --diagnostics

Diagnostics comparison from this branch:

• base: symbols 127252, types 59180, instantiations 86295, memory 220514K, check 2.71s, total 4.07s
• patched: symbols 127573, types 59331, instantiations 86597, memory 223940K, check 2.78s, total 3.86s

[github-actions]

Thanks for the PR!

This section of the codebase is owned by @saschanaz - if they write a comment saying "LGTM" then it will be merged.

[Kelpy2004]

@microsoft-github-policy-service agree

[HolgerJeromin]

This was rejected in the past

#302 (comment)

[Kelpy2004]

This was rejected in the past

#302 (comment)

Thanks for linking that. I dug through #302, microsoft/TypeScript#17818, #811, and #842 to make sure I understood the previous decision.

My read is that the old rejection was about compiler/type-checking cost from using this in the DOM hierarchy, especially through HTMLElement. I also saw that the later concrete-overload approach in #811 was reverted in #842 because it caused a jQuery / @types/tablesorter variance issue.
I rechecked both concerns on this branch with the current compiler:

• DOM-only diagnostics stayed very close: +321 symbols, +151 types, +302 instantiations, with check time effectively unchanged in my local run.
• The known @types/jquery + @types/tablesorter case from the revert history still passes under --strict --skipLibCheck false.
• The new test also covers Node, normal elements, fragments, unions, and a custom HTMLElement subclass.

So I agree this is the same area as the older rejected attempts, but I think the current compiler behavior may be worth re-evaluating rather than treating #302 as a direct blocker.
If maintainers still want to avoid this on Node, I can pivot this to a smaller concrete-return compromise, but that would intentionally not preserve exact custom element subclass types.